Participant suggestion system

ABSTRACT

A server system hosts a plurality of conversations, each having an identified set of participants. For a respective conversation, the server accesses the conversation in which a user is a participant. The server obtains a conversation profile for the conversation, the conversation profile based on information including content of the conversation and user-specific term weights for at least a plurality of terms in the content of the conversation. The server accesses a plurality of entity profiles that are based on content and/or structure in other conversations in which the user is a participant. The server compares at least a subset of the entity profiles to the conversation profile to identify a set of entities having entity profiles that best match the conversation profile, generates a suggestion for the user including a suggested entity from the identified set of entities; and sends the suggestion to the client system for display to the user.

RELATED CASES

This application is related to U.S. Provisional Patent Application61/162,642 filed Mar. 23, 2009, which is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

The disclosed embodiments relate generally to communication systems.More particularly, the disclosed embodiments relate to methods, systems,and user interfaces for transmitting, receiving, and renderingelectronic messages and suggesting entities such as participants andcategorization entities for association with the electronic messages.

BACKGROUND

A variety of electronic communications systems, including electronicemail (“email”) systems and instant messaging (IM) system are wellknown. In both email and IM systems, individual messages can beforwarded and replied to. However, for both email and IM, responding toportions of a message or forwarding portions of a message is relativelydifficult or awkward. Further, for a conversation with several levels(e.g., a conversation that includes multiple messages and responses ondifferent topics or subtopics) it can be difficult to discern thelogical context of at least some of the messages in the conversation.Similarly, the logical context of a conversation can get lost if aparticipant joins the conversation mid-way through.

Instant messaging is sometimes called electronic chat. A popularelectronic chat program is, for example, Instant Messenger, a trademarkof America Online. Electronic chat is comparable to a telephoneconversation in terms of function and structure. There is generally nological structure to an electronic chat conversation, just a timeline.

As users access electronic messages from a plurality of devices (e.g.,laptop, mobile phone, electronic pager, set top box, etc.) it would behelpful to have full access to entire conversations from each of thesedevices, and to be able to discern the logical context, within aconversation, of each user contribution to the conversation.

Additionally, users often have a large number of contacts, labels,folders, tags and other entities that can be associated withconversations. It would be helpful to have a way to accurately suggestentities for association with the conversation to a user who is aparticipant in the conversation so as to improve the user experience.

SUMMARY OF DISCLOSED EMBODIMENTS

In one aspect of the method and system, a server system having one ormore processors and memory, accesses a conversation in which a user is aparticipant, obtains a conversation profile for the conversation. Theconversation profile is based on information including content of theconversation and user-specific term weights for at least a plurality ofterms in the content of the conversation. The server accesses aplurality of entity profiles corresponding to the user, each entityprofile corresponding to a respective entity in other conversations inwhich the user is a participant and based on content in said otherconversations. The server compares at least a subset of the entityprofiles to the conversation profile to identify a set of entitieshaving entity profiles that best match the conversation profile,generates a suggestion including a suggested entity from the identifiedset of entities; and sends the suggestion to the client system fordisplay.

In some embodiments, the user-specific term weights are stored in a userprofile. In another aspect of the method and system, the servergenerates an entity profile and a conversation profile. The servergenerates an entity profile for a respective entity by selecting asubset of conversations in which the user is a participant so as toinclude only conversations associated with the respective entity andgenerating an entity vector that includes a plurality of elements, wherean element in the entity vector is associated with a respective term andcorresponds to a number of instances of the respective term in the setof conversations. The server generates a conversation profile for arespective conversation by generating a conversation vector including aplurality of elements, where an element in the conversation vector isassociated with a respective term and corresponds to a number ofinstances of the respective term in the conversation, and theconversation includes a plurality of terms. In accordance with thisaspect, the server compares a respective entity profile to theconversation profile by calculating a dot product of the entity vectorof the respective entity profile with the conversation vector.

In some embodiments, the conversation has at least a second participantin addition to the user, and the second participant has a secondconversation profile for the conversation that is based on respectiveterm weights, for a plurality of respective terms, specific to thesecond participant. In some embodiments, the entity profile for arespective entity is determined based on respective user-specific termweights for a plurality of terms.

In another aspect of the method and system, the server generates entityprofiles and conversation profiles by adjusting the counted occurrencesbased on internal structure of a respective conversation of theplurality of conversations. In accordance with this aspect, when theinternal structure of the respective conversation indicates a strongconnection between the user and a subset of the conversation, thecounted occurrences of terms in the subset of the conversation are givengreater weight than a predefined normal weight by the server. In someembodiments, the respective entity represents a contact of the user andthe internal structure of the respective conversation indicates a strongconnection between the contact and the user for a subset of theconversation when the subset of the conversation includes one or moreof: a contribution by the contact to a subset of the respectiveconversation that was created by the user, a contribution by the user toa subset of the respective conversation created by the contact, and asubset of the conversation that was concurrently edited by the user andthe contact.

In another aspect of the method and system, the sever accesses aconversation in which a user is a participant and obtains a conversationprofile for the conversation. The conversation profile is based oninformation including content of the conversation. The server furtheraccesses a plurality of entity profiles corresponding to the user. Atleast a subset of the entity profiles correspond to respectivecategorization entities in other conversations in which the user is aparticipant and are based on content in said other conversations. Theserver also compares one or more of the entity profiles to theconversation profile to identify a set of entities having entityprofiles that best match the conversation profile; generates asuggestion including a suggested categorization entity from theidentified set of entities; and sends the suggestion to the clientsystem for display. In some embodiments, the categorization entitiesinclude one or more tags and one or more labels. In some embodiments,the categorization entities include one or more folders.

In another aspect of the method and system, the server accesses aconversation in which a user is a participant and obtains a conversationprofile for the conversation. The conversation profile is based oninformation including content of the conversation. The server furtheraccesses a plurality of entity profiles corresponding to the user. Eachentity profile corresponds to a respective entity in other conversationsin which the user is a participant and is based on an internal structureof content in said other conversations. The server also compares atleast a subset of the entity profiles to the conversation profile toidentify a set of entities having entity profiles that best match theconversation profile; generates a suggestion including a suggestedentity from the identified set of entities; and sends the suggestion tothe client system for display.

In another aspect of the system and method, a server system having oneor more processors and memory, accesses a conversation in which a useris a participant; and obtains a conversation profile for theconversation. The conversation profile is based on information includingcontent of the conversation. The server system further accesses aplurality of entity profiles corresponding to the user. Each entityprofile corresponds to a respective entity in other conversations inwhich the user is a participant and is based on an internal structure ofcontent in said other conversations. The system further compares atleast a subset of the entity profiles to the conversation profile toidentify a set of entities having entity profiles that best match theconversation profile; generates a suggestion including a suggestedentity from the identified set of entities; and sends the suggestion tothe client system for display.

In some embodiments, prior to accessing the plurality of entityprofiles, the server system generates an entity profile for a respectiveentity based on an internal structure of content in respective ones ofsaid other conversations. In some embodiments, when the internalstructure of content of one of the respective other conversationsindicates a stronger connection between the user and a subset of therespective other conversation than for other subsets of the respectiveother conversation, generating an entity profile for the respectiveentity includes giving greater weight than a predefined normal weight tocontent in the subset of the respective other conversation. In someembodiments, the respective entity represents a contact of the user; andthe internal structure of the respective other conversation indicates astronger connection when the subset of the respective other conversationincludes one or more of: a contribution by the contact to content thatwas created by the user, a contribution by the user to content that wascreated by the contact, and content that was concurrently edited by theuser and the contact. In some embodiments, the internal structure of therespective other conversation indicates a stronger connection when thesubset of the respective other conversation includes one or more of:content added by the user; content edited by the user; a response fromanother participant to content added by the user; and recently addedcontent.

In some embodiments, obtaining the conversation profile includesgenerating the conversation profile based on an internal structure ofcontent in respective ones of said other conversations. In someembodiments, when the internal structure of the conversation indicates astronger connection between the user and a subset of the conversationthan for other subsets of the conversation, generating the conversationprofile includes giving greater weight than a predefined normal weightto the subset of the conversation. In some embodiments, the respectiveentity represents a contact of the user; and the internal structure ofthe conversation indicates a stronger connection when the subset of theconversation includes one or more of: a contribution by the contact tocontent that was created by the user, a contribution by the user tocontent that was created by the contact, and content that wasconcurrently edited by the user and the contact. In some embodiments,the internal structure of the conversation indicates a strongerconnection when the subset of the conversation includes one or more ofcontent added by the user; content edited by the user; a response fromanother participant to content added by the user; and recently addedcontent.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingDescription of Embodiments herein, in conjunction with the followingdrawings in which like reference numerals refer to corresponding partsthroughout the figures.

FIG. 1 is a block diagram illustrating an exemplary distributed computersystem according to certain embodiments of the invention.

FIG. 2 is a block diagram of a distributed system including aconversation server and clients coupled by one or more communicationnetworks, according to certain embodiments of the invention.

FIGS. 3A-3C are block diagrams of data structures for a conversationdatabase, a participant list and a conversation log, respectively,according to certain embodiments of the invention.

FIG. 4 is a block diagram illustrating a data structure for a userdatabase, according to certain embodiments of the invention.

FIGS. 5A-5E are flowcharts representing a method for hostingconversations at a server, according to certain embodiments of theinvention.

FIG. 6 is a block diagram of a plurality of linked conversation serversystems, with mechanisms for obtaining and distributing user onlinepresence information, according to certain embodiments of the invention.

FIG. 7 is a block diagram of a conversation server for a hostedconversation system, according to certain embodiments of the invention.

FIG. 8 is a block diagram of a client having a user who participates inone or more conversations in a hosted conversation system, according tocertain embodiments of the invention.

FIGS. 9A-9B illustrate a series of windows showing successive edits to aconversation by a plurality of participants of the conversation, andplayback of those edits.

FIG. 10 illustrates a series of windows showing solo and team-baseddrafting of a conversation.

FIGS. 11A-B are flowcharts representing a method for editing, playbackand drafting of conversations hosted at a server, according to certainembodiments of the invention.

FIG. 12 illustrates a process diagram showing concurrency controlbetween a plurality of potentially conflicting edits received from aplurality of participants.

FIG. 13 illustrates two sequences of separate edit operations, bothperformed on the same content unit, where one sequence is received froma first participant and a second sequence is received from a secondparticipant in a conversation, and transforms thereupon.

FIG. 14 illustrates first and second sequences of edit operations,applied to a content unit of an electronic conversation, received from afirst participant and a second participant, respectively, andtransformed sequences of merged edit operations corresponding to thereceived first and second sequences of edit operations.

FIG. 15 is a flowchart representing a method of concurrency control at aserver, and at a client, when a plurality of participants in aconversation make potentially conflicting edits to the conversation.

FIG. 16 is a block diagram of a distributed client-server computingsystem.

FIGS. 17A-17F are flow charts representing a method for suggestingentities to add to a conversation in accordance with some embodiments.

FIGS. 18A and 18C illustrate exemplary data structures for storingprofiles in accordance with some embodiments.

FIGS. 18B and 18D are exemplary formulas for use in generating contextweights for profiles in accordance with some embodiments.

Like reference numerals refer to corresponding parts throughout thedrawings.

DESCRIPTION OF EMBODIMENTS

Methods, systems, user interfaces, and other aspects of the inventionare described. Reference will be made to certain embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention will be described in conjunction with theembodiments, it will be understood that it is not intended to limit theinvention to these particular embodiments. On the contrary, theinvention is intended to cover alternatives, modifications andequivalents that are within the spirit and scope of the invention. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

Moreover, in the following description, numerous specific details areset forth to provide a thorough understanding of the present invention.However, it will be apparent to one of ordinary skill in the art thatthe invention can be practiced without these particular details. Inother instances, methods, procedures, components, and networks that arewell known to those of ordinary skill in the art are not described indetail to avoid obscuring aspects of the present invention.

FIG. 1 is block diagram illustrating an exemplary distributed computersystem 100 according to certain embodiments of the invention. Computersystem 100 includes a plurality of clients 110. Users of the clients 110(also herein called client devices or client systems) are participants112 in conversations hosted by a set of conversation servers 130(sometimes called a conversation server system). The clients 100 can beany of a number of computing devices (e.g., Internet kiosk, personaldigital assistant, cell phone, gaming device, desktop computer, laptopcomputer, handheld computer, tablet computer, or combinations thereof)used to enable the activities described below. Each client 110 iscoupled to a network 120, which can be any of a number of networks (e.g.Internet, intranet, local area network, wide area network, wirelessnetwork, wired network, optical network, or a combination of suchnetworks). More generally, the clients 100 and conversation servers 130are coupled to each other via one or more communication networks 120.

A respective client 110-B executes a client application 114 thatfacilitates access from the client 110 to a respective hostedconversation server 130. The client application 114 may include agraphical user interface. For example, the client application may be aweb browser or other browser application, such as Firefox (trademark ofMozilla Foundation), Internet Explorer (trademark of MicrosoftCorporation), Safari (trademark of Apple Inc.), or Chrome (trademark ofGoogle Inc.).

While a system 100 may have a single conversation server 130, in otherembodiments the system 100 may have multiple conversation servers 130.For example, multiple conversation servers 130-A and 130-B may be hostedby different service providers, such as providers 116-A and 116-Brespectively. In some embodiments, the providers are internet serviceproviders (ISPs) providing a conversation service. Alternately, some orall of the providers may be dedicated conversation providers. When thesystem 100 includes multiple conversation servers 130, the conversationservers 130 may be coupled together directly, or by a local area network(LAN), or via the network 120.

The conversation server(s) 130 host conversations between participants112. More specifically, each conversation server 130 hosts conversationson behalf of a set of users. At least some of those users aresubscribers of the hosted conversation system 100 and thus have useraccounts. As described in more detail below, some of the conversationparticipants need not be subscribers of the hosted conversation system.When new content is added to a conversation by any participant, or anyother changes are made to a conversation by any participant, the updatesare sent to all the conversation servers 130 that host conversations forthe participants in the conversation. Those host servers, in turn, sendthe updates to the clients 110 being used participants in theconversation. The conversation updates may be sent relativelyinstantaneously (e.g., within a second or two) to the clients 110 ofactive participants in the conversation. Optionally, clients 110 ofpassive participants 112 who are online and logged into the conversationsystem 100, but who are not currently viewing the conversation or arenot current participating in the conversation, receive information thatthe conversation has been updated, without receiving the updates to theconversation. In at least some embodiments, when the participant “opens”the conversation (selects it for viewing), the updated conversation isdownloaded to the participant's client from conversation server 130 thathosts conversations for that user.

FIG. 2 is a block diagram of system 200 illustrating exemplaryembodiments of a conversation server 130 and client systems 210 and 220.System 200 includes a communications network 120, as described above,coupled between a conversation server 130 and a plurality of theclients, including client 210. Client 210 corresponds to a respectiveclient 110 of FIG. 1, and is sometime herein called a “participantclient” because the user of client 110/210 is a participant in one ormore conversations hosted by the conversation server 130. System 200includes at least one participant client 210. Participant client 210optionally includes a browser 212, such as a web browser, or otherclient application to facilitate participant interaction with arespective conversation server 130. The browser 212 typically includes(or controls) a virtual machine (e.g., a Java virtual machine) forexecuting software embedded in web pages and other documents rendered bythe browser 212. In some embodiments, the browser 212 executes aconversation application 214 that is embedded, at least in part, in aweb page. The web page (which may be called a “hosted conversation webpage”) is downloaded from a server, such as a conversation server 130,to the client 210 and includes executable instructions that are executedby the virtual machine of the browser 212 in the client 210. The browser212 and conversation application 214 together form the clientapplication 114 of FIG. 1. The conversation application 214 facilitatesparticipant interaction with the conversation server system 130.

In some other embodiments, conversation application 214 is a plug-in orextension of the browser application 212.

System 200 optionally includes non-subscriber clients 220.Non-subscriber clients 220 enable users who do not have accounts in theconversation system to participate, in at least a limited manner, inhosted conversations. Participation in hosted conversations may belimited in a number of ways, for example by allowing the user of anon-subscriber client to read the content of a conversation, andallowing the user to contribute new content, but not allowing the userof the non-subscriber client to use other features such as editingcontent already in the conversation, responding to specific portions ofcontent previously contributed by other participants, and playing back aconversation.

Non-subscriber clients 220 access the conversation server system 130 ina manner that is distinct from the manner used by clients 210 whoseusers are subscribers of the hosted conversation system. An example of anon-subscriber client 220 is a weblog (“blog”) server 226, having aweblog client 228. As described below, a hosted conversation can includea weblog 228 (also called a weblog client) as a participant in theconversation, in which case content of the hosted conversation ispublished in the weblog. The published conversation is visible on theweblog 228, which is hosted by the weblog server 226. More specifically,when a weblog 228 is added as a participant to a conversation, contentof the conversation is transmitted to (also called “posted to”) theweblog 228 by the conversation server 130 that hosts the conversation.After the weblog 228 is added as a participant, new content added to theconversation is also transmitted to the weblog 228 by the conversationserver 130 that hosts the conversation. A user (e.g., a user of anotherclient 110, FIG. 1) who views content of the weblog 228 (e.g., byvisiting a URL associated with the weblog 228, hosted on the weblogserver 226) can view content of the conversation published on theweblog.

Another example of a non-subscriber client 220 is an email server 224,having email clients 222. Content from host conversations can be sent toone or more email clients 222 of one or more email servers 224. Inparticular, when the user of an email client 222 is added as aparticipant to a conversation, content of the conversation (and contentsubsequently added to the conversation) is transmitted to the emailclient 222 by the conversation server 130 that hosts the conversation.

Weblogs and email servers are also examples of “automated clients.”Other examples of automated clients include services, such as archivalservices, translation services, spell-check and grammar-check services,that may be invoked to provide services to other participants of ahosted conversation.

In some embodiments, email clients 222 and weblog clients 228 can readbut cannot provide content to a hosted conversation, and thus are justobservers. However, in some other embodiments, authoring capabilities(the ability to provide content to a conversation) are provided to atleast some “email participants” (i.e., users of email clients) or“weblog participants” (i.e., weblog clients).

In some embodiments, a conversation server 130 includes a front-end orconversation engine 246 for managing conversations and communicationswith clients, and one or more auxiliary services (modules, applicationsor servers) 250 for managing services related to conversations. In someembodiments, auxiliary services 250 include spell checking 252, languagetranslation or localization 256, and managing attachments 258 toconversations. Conversation server 130 also includes online presenceservices 248, enabling users to know the online status of other users(e.g., other subscribers of the hosted conversation system), asdescribed in detail below with reference to FIG. 6. Server 130 includesa user database 270, described in detail below with reference to FIG. 4.

The front-end or conversation engine 246 utilizes (or, alternatelyincludes) an update, access and search/query engine 260 to provideparticipant access to conversations, and to provide search functions inconversations. In some embodiments, one or more conversation indexes 264are inverse indexes, mapping words or terms in conversations to theconversations in which they occur. The one or more conversation indexes264 are used to find conversations in a hosted conversation database 262that match specified search queries. As content is added toconversations in the conversation database 262 the one or moreconversation indexes 264 are updated with that content so as to make theadded content accessible by the execution of search queries. Theconversation database 262 is described in more detail below withreference to FIG. 3.

Optionally, conversation server 130 includes an SMTP gateway 242 forfacilitating email communication with one or more email servers 224.

In the discussion below, a subscriber is a user for whom a conversationserver 130 (e.g., any conversation server 130 in a set of conversationservers 130 that provide conversation services) maintains a user recordor profile (see 402, FIG. 4, as described below).

As described in more detail below, in some embodiments, the conversationserver 130 maintains for a respective user/subscriber a list 414 (FIG.4) of conversations in which the user/subscriber is a participant. Theconversation server 130 updates the status (conversation state 438-1,FIG. 4) of each such conversation in the user's conversation list 414when the state of the respective conversation changes. When (e.g., inresponse to a search/query from the user) the conversation server 130sends to the user a requested list of conversations (typicallycomprising a subset of the complete set of conversations in which theuser is a participant), the list includes status information for thelisted conversations. The status information in the returned list isgenerally a subset of the conversation state 438, as only a portion ofthe conversation state (e.g., whether there is any content in theconversation that has not yet been viewed by the user) is needed whendisplaying the list of conversations.

FIG. 3A is a block diagram illustrating exemplary data structures forconversation database 262. While most conversations have a single set ofparticipants that share all the content of the conversation, someconversations, herein called waves or conversation containers, have amore complicated structure. In particular, a first conversation canresult in any number of “side conversations” by various subsets of theparticipants in the first conversation, and can even include additionalparticipants. For example, a conversation container or wave can be usedby two or more teams of participants (e.g., Team A and Team B) tonegotiate an agreement, or to co-edit a document or presentation or thelike. To accommodate the needs of all the participants, an initialconversation (sometimes called the primary conversation or masterconversation) is started among all the participants, and then “privateconversations” are spawned off the initial conversation to enableparticipants in each of the teams to communicate privately with otherparticipants of the team, while still having access to all of thecontent of the initial conversation. Typically, each privateconversation has a set of participants that excludes at least oneparticipant in the primary conversation. Optionally, a privateconversation can include one or more additional participants (e.g., aconsultant) who is not a participant in the primary conversation. Eachparticipant only has access to the content of the conversations in whichthey are a participant. Typically, the participants on Team A haveaccess to the content of both the Team A private conversation and theprimary conversation, and the participants on Team B have access to thecontent of both the Team B private conversation and the primaryconversation.

FIG. 3A is a block diagram of exemplary data structures that supportboth simple conversations (i.e., single conversations with no relatedprivate conversations) as well as waves or conversation containers thatinclude multiple conversations (sometimes called a primary conversationand one or more sub-conversations).

Conversation database 262 includes a plurality of wave records 302-1 to302-N, each containing the data for a wave or conversation container.When a respective wave has only one conversation, the only informationin the corresponding wave record 302 is for the single conversation, asrepresented by one conversation record 310. More generally, a waverecord 302 includes one or more conversation records 310-1 to 310-C.Each conversation record 310 contains data for a respectiveconversation, including:

-   -   wave identifier 329, which uniquely identifies the wave (i.e.,        conversation container) in the conversation system 110/200 that        corresponds to the wave record 302;    -   conversation identifier 330, which in combination with the wave        identifier 329 uniquely identifies the conversation in the        conversation system 100/200 that corresponds to the conversation        record 310 (i.e., a conversation can only be associated with a        single wave);    -   conversation metadata 322;    -   conversation log 324 (sometimes called the history log); and    -   one or more content contributions 326-1 to 326-n; and    -   a history log 360.

Conversation metadata 322 is metadata for the conversation correspondingto the conversation record 310 and identified by conversation identifier310. In some embodiments, the conversation metadata 322 includes aconversation creation timestamp 331 (indicating the date and time theconversation was created), and a list of participants 332 (described inmore detail in FIG. 3B) for the conversation. The metadata 322 mayoptionally include other metadata, such as metadata identifying tags 325(e.g., system and/or user assigned labels that are “public,” and thusavailable to all participants in the conversation) associated with theconversation, and other characteristics of the respective conversationassociated with the conversation record 310.

When a wave contains more than one conversation, the participant list332 for the primary conversation of the wave will typically include allthe participants in all the conversations in the wave. However, in someembodiments, private conversations (i.e., conversations other than theprimary conversation) in the wave can have additional participants thatare not participants of the primary conversation. Furthermore, asindicated above, each of the private conversations in a wave willtypically have a participant list 332 does not include at least one ofthe participants in the primary conversation of the same wave.

In addition, when a wave contains more than one conversation, a parentID/insertion position 333 is provided for each of the privateconversations, but not for the primary conversation. The parentID/insertion position 333 identifies the parent of the privateconversation, as well as the position in the identified parentconversation at which content of the private conversation should beinserted when viewed by participants of the private conversation.Typically the parent of a private conversation is the primaryconversation of the wave, but in some instances the parent of a privateconversation can be another parent conversation that is higher up in thehierarchy (or graph) of conversations in the wave. When a participant ofa private conversation views the wave that includes the privateconversation, the content of both the parent conversation and theprivate conversation will be seen (assuming the participant is also aparticipant of the parent conversation). In the less common situation,in which a user is a participant of a private conversation, but is not aparticipant in the parent conversation, the user will see only thecontent of the conversation (or conversations) in the wave for whichthey are a participant.

In some embodiments, the conversation log 324 (FIG. 3C) records allchanges to the conversation, including changes to the content of theconversation as well as to the set of participants and othercharacteristics of the conversation. The conversation log 324 isaccessed when participants ask to see the state of the conversation, ora content unit of the conversation, at one or more points in time. Forexample, the conversation log 324 can be used to reconstruct or reviewthe sequence of edits made to a content unit of the conversation. Thisis sometimes called “playing back” or “playback” of the conversation.Playback of a conversation can be performed in a variety of ways,including time forward or time backward, and showing updates to just aportion of the conversation or to the entire conversation.

A respective content contribution 326 (also called a content unit, or“blip”) in a conversation can be a message, much like an email messageor instant message. Other content contributions 326 in a conversationcan be documents (e.g., a report, meeting agenda, etc.), pictures,presentations, audio files, video files, or virtually any other type ofelectronic document or content. In some embodiments, there are few ifany distinctions between email messages and other types of contentcontributions to a conversation. In some embodiments, the data in aconversation record 310 for each content contribution 326 includes:

-   -   a content identifier 342 (e.g., a value uniquely identifying the        content contribution, either globally within the conversation        system, or locally within a particular conversation);    -   content unit metadata 346, identifying characteristics of the        content contribution 326;    -   optionally, one or more attachments 344 (e.g., pictures, videos,        documents, files, archives, audio, animations, links, etc.); and    -   the content 349 (e.g., text, images, document content, etc.) of        the content contribution 326.

In some embodiments, content unit metadata 346 for a content unit 326includes:

-   -   a first timestamp 341-1 denoting the date and time the content        unit was first created (added to the conversation), and a        corresponding sequence number 343-1 corresponding to the state        of the conversation when the content unit was first created;    -   a last timestamp 341-2 denoting the last date and time that the        content unit was edited, and a corresponding sequence number        343-2 corresponding to the state of the conversation when the        last edit to the content unit was made; having both the first        and last timestamps and sequence numbers is useful (for example)        when playing back changes to the content unit, or when playing        back changes to a portion of the conversation that includes the        content unit; and    -   identifiers 352 (e.g., participant addresses) of the content        unit's contributors or author(s), optionally ordered by the        order of first contributions of each author to the content unit;        while most content units have a single author, content units can        be written collaboratively, in which case they have multiple        authors.

In some embodiments, the metadata 346 for a content unit 326 alsoincludes one or more of the following:

-   -   parent identifier 354 provides an identifier of or pointer to        the parent content unit to which this content contribution is a        response or reply;    -   position 350 provides an indicator of the position of this        content unit in a conversation); the position 350 may be used to        govern how the content unit is displayed when displaying two or        more content units of the conversation; and    -   optionally, siblings 358 of this content contribution (i.e.,        identifiers or pointers to sibling content units, which are        other responses or replies to the parent of this content unit).

Typically, the metadata 346 for a content unit 326 includes at least onevalue (e.g., position 350 or parent identifier 354) that identifies orrepresents the position of the content unit 326 in the conversation.

A conversation index 264 (see FIG. 2) enables fast access toconversations in the conversation database 262 through searches of theindex.

FIG. 3B is a block diagram illustrating data structures for theparticipant list 332 in the conversation metadata 322 (FIG. 3A) of aconversation record 310. A participant list 332 includes a plurality ofparticipant records 362, one for each participant in a respectiveconversation. In some embodiments, each participant record 362 includesthe following information, or a subset of the following information:

-   -   a conversation identifier 371;    -   a participant address 372, which may also be called a        participant identifier; the participant address uniquely        identifies the participant among all the participants in        conversations in the conversation system 100 (FIG. 1);    -   a per-user conversation state 373; for example, the conversation        state 373 may indicate the read/unread state 374 of this        conversation with regard to the respective participant        corresponding to participant record 362; the conversation state        372 may include information about which content contributions in        the conversation have been viewed by the participant, and which        have not yet been viewed;    -   the conversation state 373 for a conversation participant may        include flags 376; optionally, the flags 376 may include an        ignore flag 377 (also sometimes called the mute flag), which if        present, indicates that the participant has instructed the        conversation system not to notify the participant of updates to        the conversation;    -   the conversation state 373 for a conversation participant may        include private labels (sometimes called “folders” or “folder        designations”) 378 assigned by this participant to this        conversation, which are for use only by this participant (e.g.,        when searching for conversations, the participant can include a        private label as one of the query terms); private labels can e        applied by participants to help organize their conversations and        to make it easy to locate conversations based, in part, on what        labels have been applied to them; it is noted that tags 325 are        public information, available to all participants in a        conversation, while the private labels of each participant are        private to that participant;

the conversation state 373 for a conversation participant may include aviewpoint pointer 379, which indicates either the portion of theconversation currently being viewed by the participant (and the positionof the user's cursor within a respective content unit if the user isentering or editing a content unit), or the portion of the conversationlast viewed by the participant if the participant is not currentlydisplaying or viewing the conversation;

-   -   optionally, other metadata related to this respective        participant with respect to this particular conversation.

Another optional flag 376 in the per-user conversation state 373 for arespective participant is a reminder flag. When included in the per-userconversation state 373, the per-user conversation state 373 alsoincludes a corresponding timestamp indicating the date and time (or pairof timestamps to indicate a range of dates/times) at which to reminderthe participant to pay attention to the conversation or a portionthereof, optionally a user ID identifying the user who initiated thereminder (in some embodiments, reminders can be sent by a user not onlyto themselves, but to other participant(s) in the conversation), andoptionally a content range indicator for specifying a portion of theconversation that is the subject of the reminder.

Another optional flag 376 in the per-user conversation state 373 for arespective participant is a ping flag. A ping flag is included in theper-user conversation state 373 when another participant has sent a ping(which is a form of notification, or instant message) to the participant(typically an online participant), or when the participant has sent aping to another participant. The ping flag, when present, indicates tothe client application that a ping notification (e.g., a pop-up box) isto be displayed.

Much of the information (e.g., conversation state 373) in eachparticipant record 362 is private to that participant and is not sharedwith other participants of the conversation or other users in theconversation system. In some embodiments, the cursor position (see 379,FIG. 3B) of each participant who is actively editing a content unit orentering new text in a conversation is published to and visible to otherparticipants of the conversation, unless a respective participant haselected to suppress publication of their cursor position, in which casethat aspect of the participant's conversation state 373 is notconsidered to be private to the participant. When there are a pluralityof active participants who are editing the same conversation, cursorposition information for each of the active participants is transmittedto the clients of the active participants (via their hostingconversation servers). At the client of a respective participant, aplurality of cursor positions (corresponding to a plurality of differentparticipants) are concurrently displayed when the cursor positions aresufficiently close to each other to enable concurrent display.

As described above, in some embodiments, for each respectiveconversation record 310, the server 140 maintains for each respectiveparticipant 362 a conversation state 373 of the respective conversationin regard to the respective participant. The server 130 provides to therespective participant (e.g., to a client that is displaying theconversation to the participant) the state of the respectiveconversation in regard to the respective participant. In someembodiments, this includes providing to the participant (e.g., to theclient being used by the participant) the read status of the contentunits of the respective conversation in regard to the participant (i.e.,indicating which content units have already been read or viewed (intheir current state) by the participant, and which have not). In someembodiments, providing the conversation state 373 of the respectiveconversation in regard to the respective participant includes providinglabels 378, specified by the respective participant for the respectiveconversation.

In some embodiments, providing the state 373 of the respectiveconversation in regard to the respective participant includes providing,in accordance with instructions from the participant, metadata (e.g.,ignore flag 377) to ignore the respective conversation. This provides aparticipant with an option to manage conversations in accordance with arule, in effect to archive conversations, and to reduce congestion in aconversation viewer. For example, when a participant marks aconversation with a system defined label of “ignore” or “mute,” theignore status flag 377 for the participant (for the marked conversation)is set, and the conversation is thereafter treated (on behalf of thisparticular participant) much like an archived message or conversation.Other participants of the conversation may continue to see theconversation in their list of active conversations if they have notmarked the conversation with the “ignore” label.

In some embodiments, the per-user conversation state 373 for eachparticipant of each hosted conversation is stored in the conversationdatabase 262, as shown in FIG. 3A. In other embodiments, the per-userconversation state 373 for each participant of each hosted conversationis stored in the user database 400, discussed below. In yet otherembodiments, per-user conversation state 373 information (for eachparticipant of each hosted conversation) is stored in a separatedatabase or server (sometimes called the “user supplement” database orserver) that is separate from the conversation database 262 and userdatabase 400. Optionally, pointers to per-user conversation state 373information (e.g., record) in the user supplement database may be storedin the user database 400 and conversation database 262. Alternately,such pointers are not stored, and the per-user conversation state 373for a particular user of a respective conversation is retrieved,typically for transmission to a client participating in theconversation, from the user supplement database on an as-needed basisand is updated in accordance with operations (e.g., reading content,entering end content, editing content, etc.) performed by theparticipant.

As described in more detail below, in some embodiments, the conversationserver 130 stores, for each respective subscriber, a contact list (416,described in FIG. 4) associated with the respective subscriber. In someembodiments, the contact list is stored in a user database 270 (FIG. 2)or 400 (FIG. 4).

When a conversation is sent to a client for display to a user, theclient receives only a portion of the conversation record 310 (FIG. 3A)for the conversation. For example, in some embodiments, the portion ofthe conversation record 310 sent to and stored at the client excludesthe conversation log 324, and the conversation state 373 of otherparticipants (except, the cursor position of other currently activeparticipants in the conversation who have not blocked the transmissionof their cursor position). In some embodiments, the conversation log 324is sent to a client 110 only when the participant at that client hasrequested playback of the conversation, or a user-specified portion ofthe conversation, or has requested to view the state of the conversationat a particular time or point in the past.

FIG. 3C is a block diagram illustrating data structures for theconversation log 324, according to some embodiments. The conversationlog 324 includes an time ordered sequence of log records 385-1 to 385-C(sometimes called log entries). A respective log record 385 includes acontent ID 386, identifying the content unit (if any) updated by theconversation edits recorded in the log record 385, metadata 388 relevantto the conversation edits recorded in the log record, references 394(e.g., one or more pointers or file names) to any attachments added tothe conversation by the conversation edits recorded in the log record,and a list of the conversation edits or changes 396 recorded in the logrecord. The metadata 388 includes a timestamp 389 and/or sequence numberthat uniquely identifies the order of the conversation edits in the logrecord, relative to the conversation edits in other log records for thesame conversation. The metadata 388 also identifies a list of authors(also called contributors) 390 of the conversation edits in the logrecord, and the starting position 392 of the conversation edits recordedin the log record 385. While the authors list 390 will contain only oneauthor for most log records 385, when multiple authors make edits orcontribute content to a content unit during a short period of time, orduring overlapping time periods, a single corresponding log record 385includes a list 390 of all of the authors who contributed to the changein the content unit recorded by that log record 385. In someembodiments, the starting position 392 is incorporated into theconversation edits 396, as an offset or position setting for the firstedit or update operation of the conversation edits 396, and in thoseembodiments the log records do not have a separate starting position 392field.

FIG. 4 is a block diagram illustrating a data structure for a userdatabase 400, according to certain embodiments of the invention. Thedatabase 400 includes a plurality of user records 402. In someembodiments, each user record 402 includes:

-   -   a user identifier 410 for a subscriber of the hosted        conversation system;    -   user metadata 412, containing information about or for the user;    -   a list of conversations 414 in which the user is a participant;    -   the user's contact list 416 (typically a list of contacts 416        that corresponds to and is personal to user);    -   optionally, labels 418 defined by the user for labeling or        classifying conversations;    -   optionally, a client device identifier and/or type 420 of a        client device being used by the user to communicate with the        conversation server, or alternately, the identifier and type of        client devices that the user has used in conjunction with the        conversation server in the past; in some embodiments, the type        of the client (e.g., desktop, cell phone, etc.) may be used to        determine what content from conversations is sent to the user;    -   optionally, preferences 422 of the user when participating in a        conversation 422;    -   optionally, an inverse index 424 associated with the user;    -   a current online status 426 of the user (e.g., offline, online,        busy, away, etc.);    -   authentication information 428 for the user (e.g., username,        password, and optionally other values for authentication of the        user);    -   optionally, other data relating to the user, such as one or more        blog URLs 430, email addresses 432, etc.

The conversation list 414 associated with a user includes a plurality ofuser-conversation records 434, each record relating to a conversation inwhich the user is a participant. Each user-conversation record 434includes:

-   -   a conversation identifier 436 that identifies the respective        conversation, and    -   per-user conversation state information 438, which may be the        same as (or a pointer to) the conversation state 373 in the        participant record 362 of a conversation record 310. As        discussed above, in some embodiments, per-user conversation        state information is stored in a separate database or server        (sometimes called the user supplement database or server), in        which case the user-conversation record 434 includes a        conversation identifier 436, but not the per-user conversation        state information 438.

As noted above, in some embodiments the system includes a separateper-user inverse index 424 for each user of the system; each such index424 is an index that maps the terms, labels, tags, etc. of theconversations in which a user is participant to the conversations (andoptionally, to the content units with the conversations, or locationswithin the conversations) containing those terms, labels, tags, etc.These per-user indices enable fast indexing and fast searching of theconversations in which a user is a participant. In some embodiments,additional indices (sometimes called “big wave” indices) are used toprovide fast indexing and access to “big wave” conversations havinglarge numbers (e.g., more than a threshold number, such as 500 or 100)of participants. In these embodiments, the content of “big wave”conversations is not indexed in the per-user inverse indices 424, and isinstead indexed in one or more “big wave” indices. Similarly, in someembodiments in which groups of users participate in conversations asgroups, additional per-group indices are used to index thoseconversations and to provide fast searching of those conversations; andthe conversations (if any) in which a respective user participates onlyas a group member are not included in the user's per-user inverse index424. Thus, when a user performs a search for conversations satisfying auser-specified query, multiple indices may be searched, in which casethe search results from the multiple indices are merged prior toreturning the search results to the requesting user.

In some embodiments, server 130 provides the same content of aconversation to all participants of the conversation, and provides eachonline participant with online presence information for the otherparticipants in the same conversation. In some embodiments, the serverallows a participant of a conversation to disable publication of theironline presence information to other participants in the conversation.In some embodiments, the server allows a participant of a conversationto selectively enable publication of their online presence informationto other participants in the conversation (e.g., allowing publication ofthe participant's online presence only to users designated by theparticipant; or alternately, disabling publication of the participant'sonline presence to users specifically designated by the participant).

In some embodiments, server 130 provides the same content to eachparticipant, formats content of the conversation to be compatible withone or more content types that a client device 110 associated with arespective participant has been configured to receive, and transmits theformatted content to the client device.

In some embodiments, when delivering the content of a conversation tocertain clients (e.g., a cell phone or PDA), conversation server 130formats the content by compressing multimedia data associated with thecontent (e.g., to reduce bandwidth requirements). In some embodiments,the server provides a subset of multimedia data associated with thecontent (e.g., a thumbnail image, or short audio/video clip) to theclient. In some embodiments, the conversation server removes multimediadata associated with the content (e.g., strips out multimedia and justprovides text) that is delivered to the client.

In some embodiments, the conversation server 130 authenticates a userusing authentication information 428 prior to providing content fromconversations to the user.

In some embodiments, the conversation server 130 sends content fromconversations in which a respective user is a participant to a weblog(e.g., weblog server 226 or weblog client 228), specified (e.g., by BlogURL 430) in the user record 402 for that user. When a respectiveparticipant in a conversation is an automated client, content of theconversation is sent to the automated client. The automated client maybe a weblog, an email server or account, or a service provider such as atranslation service, spelling checking service, or the like.

FIGS. 5A-5E are flowcharts representing methods for hostingconversations at a server, according to certain embodiments of theinvention. These methods are governed by instructions that are stored ina computer readable storage medium and that are executed by one or moreprocessors of one or more servers. Each of the operations shown in FIGS.5A-5E may correspond to instructions stored in a computer memory orcomputer readable storage medium. The computer readable storage mediummay include a magnetic or optical disk storage device, solid statestorage devices such as Flash memory, or other non-volatile memorydevice or devices. The computer readable instructions stored on thecomputer readable storage medium are in source code, assembly languagecode, object code, or other instruction format that is executed orinterpreted by one or more processors.

FIG. 5A shows a method 500 for hosting conversations at a server. Aserver hosts (502) a plurality of conversations, each having anidentified set of participants. The server is typically one of aplurality of servers that hosts conversations in a hosted conversationsystem.

The server provides (506) the same content from a conversation to allthe participants of the conversation. In some embodiments, the serveralso provides (508) online presence information of each of the pluralityof participants in the conversation to other participants in theconversation. The server receives (510) content from each of a pluralityof participants of the conversation and transmits the received contentto the other participants of the plurality of participants.

The server provides (512), upon an additional participant being added tothe conversation, the same content of the conversation to the additionalparticipant as provided to the identified set of participants, and addsthe additional participant to the identified set of participants. Asnoted above, when the additional participant is using a client capableof receiving the entire content of the conversation, the entire contentof the conversation is sent to the client currently being used by theadditional participant. As a result, a participant added to aconversation, even long after the conversation has begun, receivescontent contributed to the conversation before the participant was addedto the conversation.

In some embodiments, the server formats (514) content of theconversation to be compatible with one or more content types that aclient device associated with a respective participant has beenconfigured to receive, and transmits the formatted content to the clientdevice. In some embodiments, the server formats content from aconversation by performing at least one of: compressing multimedia dataassociated with the content, providing a subset of multimedia dataassociated with the content, and removing multimedia data associatedwith the content (e.g., removing video and audio data but leaving textcontent).

In some embodiments, the server receives (518) a search request (oftencalled a query or search query) from a participant, and provides to theparticipant a search result, including content from at least one of theplurality of conversations, in response to the search request.Alternately, or in addition, in response to the received search requestthe server provides (520) to the participant a search result thatincludes a list of one or more conversations that match the searchrequest. In some embodiments, the search request is processed by queryengine 260 (FIG. 2), using an inverse index 264 of conversation contentto identify conversations, or content within one or more conversations,that match the search request.

FIG. 5B shows a continuation of the method 500 of FIG. 5A. A servermaintains (530) for each respective participant a state of therespective conversation in regard to the respective participant, andprovides to the respective participant (e.g., to the client currentlybeing used by the participant to view the conversation) the state of therespective conversation in regard to the respective participant. In someembodiments, this includes providing (532) to the participant (e.g., tothe client being used by the participant) the read status of the contentunits of the respective conversation in regard to the participant (i.e.,indicating which content units have already been read or viewed by theparticipant, and which have not). In some embodiments, providing (534)the state of the respective conversation in regard to the respectiveparticipant includes providing labels, if any, specified by therespective participant for the respective conversation.

In some embodiments, the metadata maintained for a conversation withrespect to a particular participant includes (536) metadata to ignorethe respective conversation, in accordance with instructions from theparticipant. For example, the ignore metadata may be provided to thesearch engine 260 (FIG. 2) of the conversation server. In someembodiments, the server provides (538) formatting informationcorresponding to the conversation state, the formatting information foruse when displaying the conversation or portions thereof. In someembodiments, the formatting information includes one or more of: color(e.g., of text, background, borders), font, indenting, position (e.g.,superscript or subscript), etc.

In some embodiments, the server stores (540), for each respectiveparticipant, a contact list associated with the respective participant.

In some embodiments, the server verifies (542) (using authenticationinformation 428) that the participant is authorized to receive thecontent of a conversation, prior to providing content to a participant.

In some embodiments, the server maintains (544) a set of participants ofa respective conversation, including one or more subscribers of theserver system and an email participant identified by an email address.

In some embodiments, the server maintains (546) a set of participants ofa respective conversation, including one or more subscribers of theconversation system hosted by the server and a weblog on which contentof the conversation is posted.

FIG. 5C shows a continuation of the method 500 of FIG. 5A. In someembodiments, the server maintains (550) for a respective user (of theconversation system hosted by a set of servers that includes the server)a list of conversations in which the user is a participant. The serverupdates a status of each such conversation in the list when a state ofthe respective conversation changes. Upon request from the user (e.g.,from a client being used by the user) the server sends to the user alist comprising at least a portion of the list of conversations in whichthe user is a participant, the list including status information for thelisted conversations. In some embodiments, each respective user forwhich the server maintains (552) a list of conversations is a subscriberof the hosted conversation system.

FIG. 5D shows a method 560 of hosting electronic messages. A serverhosts (562) a plurality of conversations. The server provides (564)content of the conversation to a plurality of clients associated withparticipants of the conversation, including providing to each client allcontent of the conversation that the client has been configured toreceive.

The server receives (566) content from respective participants of theconversation and transmits to the clients associated with otherparticipants of the conversation at least a portion of the receivedcontent. The server also provides (568), upon an additional participantbeing added to the conversation, to a client associated with theadditional participant all content of the conversation that the clientassociated with the additional participant has been configured toreceive.

FIG. 5E shows a method 570 of hosting electronic messages. For at leastone of a plurality of servers, each associated with a different subsetof users, a server hosts (572) conversations initiated by the respectivesubset of users. The server receives (574) content from respectiveparticipants of the conversation and makes the content available toother participants of the conversation. For participants associated withother conversation servers, the content is transmitted to those otherconversation servers. The content is transmitted to the participantswhen they log in and request the content of the conversation.

The server also provides (576), upon an additional participant beingadded to the conversation, all the content of the conversation to aclient associated with the additional participant, or alternately, allcontent of the conversation that the client associated with theadditional participant has been configured to receive. In someembodiments, the server provides (578) a uniform view of theconversation to a plurality of the participants.

FIG. 6 is a block diagram of a conversation system 600 having aplurality of linked conversation servers 130, according to certainembodiments of the invention. FIG. 6 illustrates a logical coupling ofthe conversation servers 130 to each other and to clients for monitoringand reporting the online status (presence) of the system's users. Thenetwork 600 includes conversation servers 130-A, 130-B, and 130-C. Theconversation system 600 may include more or fewer conversation serversthan shown in FIG. 6. Each conversation server 130 hosts conversationsfor a set of users 138. (For example, each conversation server 130 mayhost conversations initiated by hundreds or even thousands of users.)Conversation server 130-A is assigned users 138-A; conversation server130-B is assigned users 138-B; and conversation server 130-N is assignedusers 138-N. Each conversation server 130 includes a respective statusmonitor 134 (134-A, 134-B, 134-N) and a respective status collector 136(136-A, 136-B, 136-N).

Whenever a user changes online status (e.g., goes from offline toonline, by logging into the conversation system), the change in statusis detected by a respective status monitor 134 (e.g., a status monitorin the conversation server 130 assigned to the user). The status monitor134 at the conversation server to which the user is assigned receives amessage or otherwise detects the change in online status of that user to“online” (or “active,” “busy,” or whatever status is appropriate).Furthermore, the status collector 136 at the conversation server gathersthe online status of the contacts in that user's contact list 416. Whilesome of the contacts in the user's contact list may be assigned to thesame conversation server, other contacts in the user's contact list areassigned to other conversation servers.

The status collector 136 of the conversation server to which the user isassigned gathers the online status of the user's contacts, includingthose assigned to other conversation servers, and forwards at least aportion of the collected status information to the user (i.e., to theclient device or system currently being used by the user). In someembodiments, the status collector broadcasts requests for statusinformation of the user's contacts to the other conversation servers,and the conversation servers to which the contacts are assigned respondto the requests. In some other embodiments, the status collectordetermines the conversation servers to which the contacts are assignedand sends requests for status information to those conversation servers.In some embodiments, the assignments of users to conversation serversmay be determined by reference to an index of all users, a copy of whichmay be stored in all of the conversation servers or a subset thereof.

For example, if a user A1 of users 138-A, assigned to conversationserver 130-A, changes online status from offline to online, a clientapplication at the client being used by the user A1 sends a message tothe conversation system 600 announcing that user A1 is online. Thestatus monitor 134-A at the conversation server 130-A receives themessage and updates the status of the user A1 to online. The statusmonitors 134 of other conversation servers either do not receive thismessage, or ignore it because the user A1 is not assigned to those otherconversation servers. The status collector 136-A at the conversationserver 130-A obtains a list of the contacts for the user A1 (e.g., byaccessing contact list 416 for user A1). Using that list of contacts,the status collector 136-A gathers status information from theconversation servers to which the contacts are assigned. Thus, if acontact is assigned to conversation server 130-A, then the statuscollector 136-A accesses the contact's status information stored atconversation server 130-A. If a contact is assigned to conversationserver 130-B, then server 130-A communicates with conversation server132-0 to get the status information. A similar procedure occurs if arespective contact is assigned to conversation server 130-C.

FIG. 7 is a block diagram illustrating a conversation server 700 (alsosometimes called a conversation system or a conversation server system)in accordance with one embodiment of the present invention. Theconversation server 700 includes one or more processing units (CPU's)702, one or more network or other communications interfaces 704, memory706, and one or more communication buses 708 for interconnecting thesecomponents. The communication buses 708 may include circuitry (sometimescalled a chipset) that interconnects and controls communications betweensystem components. The conversation server 700 optionally includes (buttypically does not include) a user interface having a display device anda keyboard.

Memory 706 includes high-speed random access memory, such as DRAM, SRAM,DDR RAM or other random access solid state memory devices; and mayinclude non-volatile memory, such as one or more magnetic disk storagedevices, optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices. Memory 706 may optionallyinclude one or more storage devices remotely located from the CPU(s)702. Memory 706, or alternately the non-volatile memory device(s) withinmemory 706, includes a computer readable storage medium. In someembodiments, memory 706 or the computer readable storage medium ofmemory 706 stores the following programs, modules and data structures,or a subset thereof:

-   -   an operating system 710 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 712 that is used for connecting        the conversation server 700 to other computers via the one or        more communication network interfaces 704 and one or more        communication networks, such as the Internet, other wide area        networks, local area networks, metropolitan area networks, and        so on; and    -   a conversation engine 714 that provides hosted conversation        services on the server 700 for a plurality of users; in some        embodiments, the conversation engine 714 corresponds to element        246 of FIG. 2.

The conversation engine 714 may include the following modules, or asubset thereof:

-   -   a search/access module 716 (in some embodiments, this        corresponds to element 260 of FIG. 2), for performing searches        of the conversation database 726; the searches of the        conversation database 726 may include user-specified searches        718 as well as server-specified searches 720 (e.g., a search for        conversations in a user's inbox);    -   a user database 722 (in some embodiments, this corresponds to        element 270 of FIG. 2 and element 400 of FIG. 4), for storing        information pertaining to users of the system;    -   user database management modules 724, for managing the user        database 722 (e.g., for creating new user records, and for        updating existing user records);    -   conversation database 726 (in some embodiments, this corresponds        to element 262 of FIG. 2 and FIG. 3);    -   conversation management modules 728, for managing the        conversation database 726; and    -   auxiliary services module(s) 250; as noted above, each        particular auxiliary service provided in a hosted conversation        system may be provided by modules within a conversation server        700, or by other servers.

In some embodiments, the conversation management modules 728 include thefollowing modules, or a subset thereof:

-   -   a set of conversation update modules 730, for updating a        conversation with changes made by one or more participants,        including one or more of: an add/delete content module 732, for        adding or removing content from a conversation; a split content        contribution module 734, for splitting a content contribution        (326, FIG. 3A) in a conversation into two or more separate        content contributions; a cooperative editing module 736, for        enabling simultaneous editing of a conversation or a content        contribution (unit of content) by a plurality of participants;        and an add new participant to conversation module 738, for        adding a new participant to a conversation;    -   content playback module 740, for playing back edits to a        conversation or document (or a user-specified portion of the        conversation or document);    -   content formatting module 742, for formatting content to match a        configuration of a client; (the configuration of a client for a        respective user may be specified by an element 420, FIG. 4, of        the user record 402 for the respective user);    -   content publication to email module 744, for publishing content        of a conversation to an email address; the email address may be        specified by an element 432, FIG. 4, of the user record 402 for        the respective user;    -   content publication to weblog (“blog”) module 746 for publishing        content of a conversation to a weblog; the URL or network        location of the weblog may be specified by element 430, FIG. 4,        of the user record 402 for the respective user)    -   delete/archive conversation module 748, for deleting or        archiving a conversation from a user's inbox or conversation        viewer;    -   copy attachments to new conversation module 750, for copying        attachments from one conversation to another conversation,        without copying other content of the conversation;    -   transmit conversation module 752, for transmitting content of a        conversation to a client or to another conversation server        (e.g., for delivery to a user/client serviced by the other        conversation server);    -   transmit conversation list module 754, for transmitting a list        of conversations to a client or to another conversation server        (e.g., for delivery to a user/client serviced by the other        conversation server);    -   auxiliary services module 756 for providing access to services        outside of the conversation server;    -   entity suggestion module(s) 758 for generating entity        suggestions for a user based on conversations associated with        one or more of the entities;    -   entity profile generator 760 for generating entity profiles for        at least a subset of the entities based at least in part on        previous conversations (it should be understood that, in some        embodiments, the entity profile generator 760 performs “offline        training” by generating entity profiles based on batches of        archived conversations, as discussed in greater detail below        with reference to FIG. 17B);    -   conversation profile generator 762 for generating conversation        profiles for one or more conversations;    -   profile comparer 764 for comparing entity profiles to a        conversation profile to determine which entity profiles best        match the conversation profile;    -   suggestion generator 766 for using the comparisons between the        entity profiles and the conversation profile to generate a        suggestion including one or more of the entities associated with        the entity profiles;    -   user profile database 768 for storing information associated        with a user including entity profiles, entity affinity scores,        term weights, etc.    -   conversation profile database (optional) 770 for storing        conversation profiles (e.g., temporarily caching conversation        profiles generated by the conversation profile generator 762);        and    -   profile generation policies 772 for providing the entity profile        generator 760 and the conversation profile generator 762 with        rules for generating profiles (e.g., the number of terms to use,        the number of entities to use, the frequency with which the        entity profiles are to be re-generated).

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and corresponds to a set ofinstructions for performing a function described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 706 maystore a subset of the modules and data structures identified above.Furthermore, memory 706 may store additional modules and data structuresnot described above.

Although FIG. 7 shows a conversation server, FIG. 7 is intended more asfunctional description of the various features which may be present in aset of servers than as a structural schematic of the embodimentsdescribed herein. In practice, and as recognized by those of ordinaryskill in the art, items shown separately could be combined and someitems could be separated. For example, some items shown separately inFIG. 7 could be implemented on single servers and single items could beimplemented by one or more servers. The actual number of servers used toimplement a conversation server system and how features are allocatedamong them will vary from one implementation to another, and may dependin part on the amount of data traffic that the system must handle duringpeak usage periods as well as during average usage periods.

FIG. 8 is a block diagram of a client having a user who participates inone or more conversations in a hosted conversation system, according tocertain embodiments of the invention. The client 800 includes one ormore processing units (CPU's) 802, one or more network or othercommunications interfaces 804, memory 806, and one or more communicationbuses 808 for interconnecting these components. The communication buses808 may include circuitry (sometimes called a chipset) thatinterconnects and controls communications between system components. Theclient 800 typically includes a user interface 805. In some embodiments,the user interface includes a display device, a keyboard and a pointerdevice (not shown), while in other embodiments (e.g., a cell phone orpersonal digital assistant) the user interface includes a touch screendisplay.

Memory 806 includes high-speed random access memory, such as DRAM, SRAM,DDR RAM or other random access solid state memory devices; and mayinclude non-volatile memory, such as one or more magnetic disk storagedevices, optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices. Memory 806 may optionallyinclude one or more storage devices remotely located from the CPU(s)802. Memory 806, or alternately the non-volatile memory device(s) withinmemory 806, includes a computer readable storage medium. In someembodiments, memory 806 or the computer readable storage medium ofmemory 806 stores the following programs, modules and data structures,or a subset thereof:

-   -   an operating system 810 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 812 that is used for connecting        the client 800 to other computers via the one or more        communication network interfaces 804 and one or more        communication networks, such as the Internet, other wide area        networks, local area networks, metropolitan area networks, and        so on;    -   a browser or other client application 814 for viewing and        interacting with web pages and other content, including        conversations in a hosted conversation system;    -   a conversation web page 815, which is received from a        conversation server (e.g., shown in FIG. 7) and is displayed        using the browser or other client application 814;    -   a conversation record 820, which contains the content of a        conversation downloaded from a conversation server, some or all        of which may be displayed in the conversation web page 815;    -   a conversation list 826, which is a list of conversations        downloaded from a conversation server (e.g., in response to a        query from a user of the client or as part of a user interface        displayed within the conversation web page 815);    -   a contact list 828, or a portion of the contact list of the user        of the client; the contact list may be maintained separately        from or in conjunction with a conversation system;    -   optionally, other data structures 830 (e.g., a list of labels        defined by the user); and    -   optionally, other applications 832 for execution by the client        800.

In some embodiments, the conversation web page 815 includes a clientconversation module 818 or other client assistant that is embedded inthe web page 815. The client conversation module 818 comprisesexecutable instructions that are executed by the client 800; forexample, the client conversation module 818 may include instructionsthat are executed by a virtual machine (e.g., a Java virtual machine)that is part of the browser 814. The conversation web page 815 includesa conversation user interface having icons, which when activated by auser, execute various tasks to enable a user to request a list ofconversations, select a conversation for display, view various portionsof a conversation, participate in the conversation (e.g., by addingcontent to or editing content of the conversation), start newconversations, download attachments, and so on. Icons in theconversation user interface may function as links to executableprocedures and instructions in the client conversation module 818. Theaforementioned conversation record 820 and conversation list 826 may, insome embodiments, be downloaded in response to instructions sent by aclient conversation module 818, or other client assistant embedded inthe web page 815, to a conversation server.

The conversation record 820 comprises a client version or subset of theconversation record 310, described above with respect to FIG. 3A, for arespective conversation. The client conversation record 820 includesconversation metadata 822 needed by the client (e.g., a list ofparticipants and their online status) and content contributions 824 thatare the content of the conversation. Depending on the implementation andthe capabilities of the client 800, the conversation record 820 mayoptionally include the attachments, if any, of the conversation. Thus,attachments may be downloaded to some clients (e.g., desktop and laptopcomputers), but not to others (e.g., mobile phones and personal digitalassistants). In some embodiments, the attachments of the conversationare not downloaded until they are requested by the user. Alternately, insome embodiments, thumbnail images and/or snippets (e.g., selected text,if any) of some or all the attachments are automatically downloaded tothe client 800 along with the primary content of the conversation, andthe full content of the attachments is downloaded to the client 800 onlyupon user request.

Each of the above identified modules corresponds to a set ofinstructions for performing the functions described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 806 maystore a subset of the modules and data structures identified above.Furthermore, memory 806 may store additional modules and data structuresnot described above.

FIGS. 9A and 9B illustrates a series of windows showing edits to aconversation by a plurality of participants of the conversation, andplayback of those edits.

FIG. 9A illustrates changes made to a conversation by a plurality ofparticipants in the conversation. In the following example, there are atleast two participants in the conversation, “Joe” and “Pat”.

At a first time/step 920, a first conversation window 910 has a firstunit of content 922 entered by a first participant (e.g., Joe), who isthe initial author of content 922. In some embodiments, the conversationwindow 910 includes a zoom option 912 to zoom deeper into aconversation, a reply option 914 to reply to the content 922, a draftoption 916 to create a draft message, or a setting option 918 to changeconversation settings. A first caret 924 represents a point (sometimesherein called a cursor position) at which the first participant istyping or editing the content 922. As the first participant types,deletes, or moves around the content 922, the caret 924 moves,indicating the location in or portion of the content that the user isediting.

In some embodiments, the caret may be defined as an XML tag or othermarkup language tag or expression. In some embodiments, the caretcontent, style, etc. may be selected or defined by a participant, by asystem administrator, etc.

At a second time/step 930, a second participant (Pat) provides asequence of edits to the content 922. A second caret 934 represents apoint at which the second participant (also called the second user) istyping or editing the content 922. The second user adds the text“Building B” 932 to the content 922. The original content (by Joe) andthe edits thereto (by Pat) are edits by distinct first and secondparticipants in the conversation.

In some embodiments, a server (e.g., hosting the conversation) preparesfor display the first caret at a position corresponding to the firstedits by the first participant (Joe) of the conversation, and preparesfor display a second caret at a position corresponding to the secondedits by the second participant (Pat) of the conversation. The serverprovides the first and second edits and the first and second carets tothe one or more servers for display.

In some embodiments, timestamps or sequence numbers (e.g., #1, #2, #3,and #4, as illustrated) may be associated with new content or edits toexisting content. In some embodiments, if a timestamp is used, thetimestamps use a consistent time base such as the time base of thehosting server.

At a third time/step 940, the second user again edits the content 922,by deleting the word “second” and replacing it with the word “third”942. The second caret 934 is now beside the word “third”, indicating thelocation where the second user is editing.

At a fourth time/step 950, first user Joe creates a new message, in anew message window 952 within the conversation window 910 and below thefirst message window (which contains content 922 of the first message),and adds new content 954 to the new message window. Caret 956 representsa new point at which the first user (Joe) is typing or editing thecontent 954 in the new message window 952.

In some embodiments, as a new content (e.g., content 922) or a sequenceof edits (e.g., edits 932, 942) are received, the conversation isupdated with the revised content unit. In some embodiments, the updatedconversation is provided to the one or more servers hostingconversations for the participants (e.g., Joe, Pat, etc.) in theconversation.

In some embodiments, a server hosting the conversation checks forconflicts between the first edits and the second edits, and if aconflict occurs, the server notifies a participant associated with theconflict. For example, if participant Pat attempts to edit a piece oftext that Joe is currently editing, such that the edits conflict witheach other (e.g., Pat deletes a word as Joe is typing it, or Joe deletesa paragraph within which Pat is editing), a conflict occurs and one orboth of the participants are notified. In some embodiments, conflictsare automatically resolved using a predefined concurrency controlprocedure, described in more detail below.

FIG. 9B illustrates playback of edits to the conversation illustrated inFIG. 9A. In some embodiments, the edits are played back in chronologicalorder, e.g., according to timestamps associated with the edits. In someother embodiments, the edits are played back according to sequencenumbers associated with the edits. A participant of the conversation mayview changes to conversation using the playback mechanism.

In some embodiments, the conversation is played back showing changeswithin a user-specified portion (e.g., a block of text, a paragraph, asingle unit of conversation (blip), etc.) of the conversation in achronological order. In some embodiments, this user-specified portion ofthe conversation is played back without viewing changes to otherportions of the conversation. In one example, the user-specified portionis a single content unit of the conversation.

In a first playback time/step, content 966 is displayed in a window 964.A forward option 962 is displayed allowing a viewer to go forward in theconversation playback.

In a second playback time/step, obtained by selecting the forward option962 in window 964, content 970 shows edits by second participant (Pat)to the conversation, adding the words “Building B.” A back option 972 isdisplayed, which allows a participant to move backward in theconversation playback, and the forward option 962 continues to bedisplayed.

In a third playback time/step, obtained by selecting the forward option962 in window 964 while viewing the second playback time/step, content980 shows further edits by second participant (Pat) to the conversation,replacing the word “second” with “third.”

In a fourth playback time/step, obtained by selecting the forward option962 in window 964 while viewing the third playback time/step, content990 shows further edits (new window 992 with text) by first participant(Joe) to the conversation. A replay option 994 allows a participant toreplay the sequence of updates to the conversation. In some embodiments,one or more playback options enable a participant to perform one or moreof the following operations: playback recent edits (e.g., most recent intime or in number), edits by a particular participant, edits to aparticular portion of the conversation, etc.

In some embodiments, a playback may only show changes by a particularparticipant of the conversation. This may allow the participant toreview his/her changes, or to view the changes of another participant.

In some embodiment, edits in the sequence of edits include individualkeystrokes of a sequence of keystrokes by a respective participant inthe conversation. In some embodiments, a plurality of distinct edits inthe sequence of edits are distinct keystrokes. In some embodiments, aplurality of distinct edits in the sequence of edits are distinct words.For example, edits 932 by participant Pat include a distinct word(Building) and a distinct letter (B), and edits 942 include a deletionoperation (delete the word “second”) and an addition operation (addingthe word “third”). In some embodiments, as each of these distinct editsis received by the server hosting the conversation, the conversation isupdated accordingly.

FIG. 10 illustrates participants preparing a message in a draft mode.While in draft mode, a participant makes edits, such as adding ordeleting content in a conversation, and the edits are received by theserver hosting the conversation, but are not sent to other participantsin the conversation. Only when the participant exits the draft mode,e.g., by indicating that he/she is finished making edits, are theparticipant's edits released (i.e., sent to the clients of the otherparticipants) by the server so that other participants can view them.The author (i.e., a participant working in draft mode) can preparecontent, knowing that intermediate changes or thoughts will not bevisible to other participants until the author is ready.

In some embodiments, when one participant is editing a content unit (ofa conversation) in draft mode, editing of the content unit by otherparticipants is disabled. Editing of other content units of the sameconversation by other participants is not disabled.

In some embodiments, a “team draft mode” allows a plurality ofparticipants (e.g., members of Team A) to work together in preparing orediting content and to see each other's edits, while preventing non-teamparticipants from seeing the content or edits until the team draft modeis exited. Using the team draft mode protects the privacy of teammembers as they work together to prepare content for publication toother participants in the conversation.

A number of different mechanisms may be used to exit the team draftmode, or to release content prepared by a team of participants. Forexample, the team draft mode may be exited (or content prepared by arespective team may be released for publication to the otherconversation participants), when team members agree that the editsshould be published. In some embodiments, in order to exit the teamdraft mode, all team members must agree to publish edits or content,while in some other embodiments a majority of team member must agree topublish edits or content, and in yet other embodiments, one or moresenior team members determine when to publish edits or content.

In the team draft mode, as a respective participant of the conversationmakes edits to the conversation, the updated conversation is provided toa server associated with a team member. In some embodiments, the editsto the conversation are provided to a server associated with a non-teammember, but display of the edits is delayed. In some embodiments, theedits to the conversation are not provided to a server associated with anon-team member until the draft mode is ended.

Further, in the ‘team’ draft mode, edits to the conversation from theparticipant (author) and one or more team members are received, theconversation is updated, and the updated conversation is provided to theone or more servers associated with the respective participant and theother team members.

In a first time/step 1010, a first author/participant (e.g., Joe, who isa member of Team A) prepares a message in window 1012. An approvaloption 1014 (e.g., using a check mark for approved and a cross 1016 fornot approved) shows that the first author has not yet approved themessage. When the first participant approves the message, this may berepresented as a check mark 1033 in option 1014. The first author enterscontent 1011, and a caret 1018 indicates the first author's current textentry or editing position in the content. In some modes of operation, asthe first author enters the content 1011, the content is made visible tomembers of the same team as the first user.

In a second time/step 1020, a second participant (Pat, who is also amember of Team A) edits the content 1011 (in this example, changing“$100” to “$110”) to produce updated content 1021. Second caret 1026shows the text entry or edit position of the second participant in thecontent. An approval option 1022 associated with the second participantis displayed at the top of the window 1012, and functions like theapproval option 1014 associated with the first participant, as describedabove. As the second participant edits the content, the updated content1021 is made visible to members of the same team.

In a third time/step 1030, the first (Joe) and second (Pat) participantsapprove the message for publication. This is indicated by check marks1033 associated with approval options 1014 (for the first participantJoe) and 1022 (for the second participant Pat). The approved content(1031) is then published to other participants in the conversation.

In a fourth time/step 1040, the edits made by first and secondparticipants are published so that conversation participants (e.g.,members of Team B) outside of Team A can now view the published content1041.

In the example shown in FIG. 10, all the team-based drafting and editingtakes place in one message window 1012 for one content unit. In otherembodiments, solo or team-based drafting can occur in more than onewindow or content unit, and can include adding new messages or editingexisting messages.

FIGS. 11A-B are flowcharts representing methods for editing, playingback and drafting conversations hosted at a server, according to certainembodiments of the invention. These methods are governed by instructionsthat are stored in a computer readable storage medium and that areexecuted by one or more processors of one or more servers, as described.

FIG. 11A shows a method 1100 for hosting conversations at a server(e.g., in hosted conversations database 262, FIG. 2). A server hosts(1102) a plurality of conversations, each having an identified set ofparticipants.

The server receives (1104) units of content (e.g., each content unitstored as a content contribution 326, FIG. 3A) from respectiveparticipants in the conversation and transmits to one or more servershosting conversations for the participants in the conversation at leastportions of the received content units. Optionally, individualkeystrokes are transmitted from the client utilized by a content unit'sauthor to other participants as the author composes the content of acontent unit (1106).

The server receives (1108) a sequence of edits, including first editsand second edits, to a respective content unit of the conversation fromat least one participant other than the initial author of the contentunit to produce a revised content unit. Optionally, the first and secondedits to the content unit are edits by distinct first and secondparticipants in the conversation (1110).

Optionally, or in some modes of operation, editing of the respectivecontent unit by other participants in the conversation is disabled(1112) while receiving edits to the content unit from a firstparticipant of the conversation. Alternately, concurrent editing by morethan one participant in the conversation is enabled (1113). As describedin more detail below, any conflicts between concurrent edits bydifferent participants are resolved and the resulting consistent contentis published to (or made available to) all the conversationparticipants.

In some embodiments, a first caret (e.g., caret 924 identifying Joe inFIG. 9A) is prepared for display (1114) at a position corresponding tothe first edits by the first participant of the conversation, and asecond caret (e.g., caret 934 identifying Pat) is prepared for displayat a position corresponding to the second edits by the secondparticipant of the conversation, and the first and second edits and thefirst and second carets (or caret positions) are provided to the one ormore servers. Active participants in the conversation (e.g.,participants whose clients are currently displaying the conversation)can see the carets associated with concurrent authors/editors of acontent unit.

In some embodiments, the plurality of edits in the sequence of editsinclude distinct keystrokes (1116). In these embodiments, the clientsused by active participants in the conversation display updates/edits tothe conversation at substantially the same time as they are entered bythe author of those update/edits.

In some embodiments, the plurality of edits in the sequence of editsinclude distinct words (1118). In these embodiments, the clients used byactive participants in the conversation display word-by-wordupdates/edits to the conversation at substantially the same time as theyare entered by the author of those update/edits.

A respective timestamp or sequence number is stored (1120) for eachdistinct edit in the sequence of edits to the content unit, includingdistinct timestamps or sequence numbers for at least first and secondedits to the content unit.

The conversation is updated (1222) with the revised content unit and theupdated conversation is automatically provided to the one or moreservers hosting conversations for the participants in the conversation.

FIG. 11B continues the method 1100 for hosting conversations at aserver, illustrated in FIG. 11A.

In some embodiments, a timestamp (e.g., timestamps 1, 2, 3, 4 indicatedby 920, 930, 940, 950, etc., of FIG. 9A and stored in timestamps 341 ofFIG. 3B) is stored (1130) for each content unit in the conversation.

Data is transmitted (1132) representing the sequence of edits to arespective participant of the conversation, thus enabling the respectiveparticipant to view changes to the conversation in accordance with thesequence of edits.

In some embodiments or modes of operation, the respective participant ispermitted to view (1134) changes to the conversation (or auser-specified portion of the conversation) in a chronological order,e.g., even if the changes are spaced apart from each other in theconversation. Stated in another way, in some modes of operation theplayback function in a client application displays a sequence of changesto the conversation in chronological order. For example, in FIG. 9B aconversation is played back to show changes to the conversation as aresult of adding and editing of content by participants in theconversation.

In some embodiments or modes of operation, the respective participant ispermitted to view (1136) a sequence of changes within a logical portionof the conversation in a chronological order, e.g., using the back 972and forward 974 buttons to navigate through changes in the conversation.Stated in another way, in some modes of operation the playback functionin a client application displays a sequence of changes within a logicalportion of the conversation in a chronological order. This allows aparticipant to see sequences of changes in a specific portion ofinterest in the conversation, without seeing changes in unrelatedportions. For example, the logical portion of the conversation for whichchanges are displayed may be a single content unit of the conversation(1138). Alternately, the logical portion of the conversation for whichchanges are shown (when using the playback function) are a plurality ofuser-selected content units of the conversation.

In some embodiments, a respective participant of the conversation ispermitted to view (1140) changes to the conversation by anotherrespective participant of the conversation, e.g., to view all changesmade by first participant Joe or by second participant Pat, asillustrated in FIG. 9A.

In some embodiments, the server delays (1142) providing edits to theconversation by a respective participant operating in a draft mode, andprovides the updated conversation to other participants (e.g., to theservers that host conversations of the other participants, and to theclients used by those other participants) until the respectiveparticipant exits the draft mode or releases the conversationedits/updates that he/she has made. For example, edits 1011, 1021 ofFIG. 10 are not provided to Team B until after members of Team A (Joe,Pat) approve the edits and end the draft mode. In some embodiments,draft mode information or draft approval information or status is storedin the participant conversation state 372 (FIG. 3B) for theconversation.

In some embodiments, while a respective participant (who is a teammember) makes edits to the conversation using a team draft mode, theserver provides (1144) the updated conversation to a server associatedwith another team member (e.g., Joe can see Pat's edits and vice versa),and delays providing the edits to the conversation by the respectiveparticipant to a server associated with a non-team member (e.g., Team Bcannot see Team A's edits during the draft mode). After the draft modeis ended, the server provides the updated conversation, including theedits to the conversation by the respective participant, to the serverassociated with the non-team member. Alternately, the conversation editsmade during draft mode are provided contemporaneously to the serversassociated with all conversation participants, but the changes aremarked as draft mode changes and therefore not provided to participantsoutside the team of the participant making the changes until the draftmode is exited or the conversation updates are approved or released(e.g., by the participant or by the participant's team).

In some embodiments, when a group or team of participants in a firstconversation initiates editing of the conversation in a team draft mode,a separate conversation is created. The team members draft contentwithin the separate conversation, and when the team is finished draftingthe separate conversation or a portion thereof is merged back into thefirst conversation, at which point the new or edited content is madeavailable to the other participants in the first conversation.

Concurrency Control

The aforementioned cooperative editing module 736 (FIG. 7) allowsmultiple participants (clients) to simultaneously edit a conversation,and provides conflict detection and resolution to determine ifparticipants' edits conflict. At a respective client, a user enters andedits conversation content using an “optimistic user interface,” whichassumes there is no conflict between content entry and edits made by theuser of the client device and other participants in the sameconversation, until it is told otherwise by the conversation server thatprovides conversation hosting services for the client.

Referring to FIG. 15, one or more participants in a conversation makeedits to a conversation at their local client (1510), which sends theuser edits (1512) to the conversation server that provides conversationservices to the client. The user edits made by each participant arereceived at the conversation server system (1520).

When conflicting changes (edits) are made by two (or more) conversationparticipants (herein called the “competing participants” for ease ofidentification, as opposed to any other participants who are notcurrently making conflicting edits to the conversation), transformationoperations are performed on the edits made by the competing participantsso that the state of the conversation on each of the clients isconsistent. Furthermore, the conversation server reduces the number oftransformation operations it needs to perform by merging sequences ofedits made at each client into merged sequences of edits (1522), andthen performing the transformation operations on the merged sequences ofedits by the competing participants (1524). Respective transformedsequences of edits are transmitted to the clients of the competingparticipants (and to any other active participants), along withsequencing information (1524, 1534)) to enable each client to apply bothlocally made edits and the received transformed sequences of edits inthe correct order so as to reproduce the correct current state of theconversation (1536).

When non-conflict changes (edits) are made by two (or more) conversationparticipants, the conversation server still merges sequences of editsmade at each client into merged sequences of edits (1522). Each mergedsequence of edits is assigned a timestamp and/or sequence number (seedescription above of conversation log 324, FIG. 3A), and is sent to theclients of the conversation participants (1522, 1530) so that all theparticipants have a consistent record of conversation state. Therespective clients apply the received merged edit sequences to updatethe locally stored conversation state (1532). Each client at which theconversation is being displayed updates its display of the conversation(1538) in accordance with both the locally made edits and the mergedsequences of edits of other participants received from the conversationserver.

A special situation requiring special handling at the client is asfollows. If, at the time a transformed sequence of edits is received ata client, the participant using the client has made additional changesthat conflict, or potentially conflict with the changes recorded in thereceived transformed sequence of edits, then the client performs asecond transformation on the received sequence of edits that anticipatesthe transforms to be made at the server when it receives the additionalchanges made at the client. As a result of the second transformation onthe received sequence of edits, and the transformation applied by theserver to the edits made at the client, the conversation state is madeconsistent across the clients of the participating users and across thehosting server(s). In other words, each of the clients includesoperation transformation instructions, to be applied to received editsmade at other clients, that take into account transformations that willbe performed by the server on the edits made at those clientsoperations. The state of the conversation at each step along the way isrepresented by a corresponding sequence number, which is used by boththe clients and the conversation hosting server to ensure that thetransformations made at the clients and servers are coordinated orsynchronized and produce a consistent conversation state. (1536).

It is noted that locally made edits are sent to the conversation server(1512) on a continuing basis, and so the edits made subsequent to thereceived transformed sequence of edit are also sent to the conversationserver, and the process of generating merged sequences of edits, andgenerating transformed sequences of edits (if needed), continues. As aresult, the state of the conversation at each client reflectsinterleaved sequences of edits by the active participants, where some ofthe sequences of edits are transformed sequences that have beentransformed in order to achieve a consistent state at each of theclients used by the conversation participants.

As discussed above, in some embodiments, concurrency control operationsfor a conversation are performed at both the conversation server system130 that hosts the conversation and, when necessary, by clients thatreceive transformed edits that conflict with intervening edits made atthose clients.

The quantity of edits that are merged into a merged edit sequence (1522)depends, at least in part, on the rate at which the participant isentering edits. Another factor that may affect the quantity of editsthat are merged is whether other participants are editing the samecontent unit at the same time. For example, when there are no competingedits being made by other participants, relatively long sequences ofedits may be merged. However, when competing edits are being made byother participants, relatively short sequences of edits (e.g., limitedto edits made in a period of N seconds, where N is typically less thanor equal to 0.5) are merged. In other embodiments, edits (which includescontent entry, as well as revisions of previously entered content, andchanges to shared metadata) by a participant are sent right away toother active participants in the conversation, if any, withoutperforming any merging. When conflicts are detected, a transformation isgenerated (at the hosting conversation server, or at another server) foreach individual edit operation before forwarding it to the other activeparticipants. As noted above, a second level transformation on arespective received transformed edit is performed at the receivingclient when the received transformed edit conflicts with an edit made atthe local client since the time corresponding to the conversation statesequence number.

To keep latency, defined as the delay between edit entry and itsappearance at the clients of other participants, low, edits byparticipants are typically sent to the other active participants asquickly as possible, without regard to edit sequence merging. Fasttransformation and forwarding of edits during “live conflicts” (when twoor more participants are revising the same portion of the conversation)keeps the participants accurately apprised of the evolving conversationstate during live conflicts. Since merging operations and thentransforming them to the active participants would increase latency,operation merging is either not used, or used only for very small timewindows, during live conflicts. On the other hand, for purposes ofrecording the conversation history in the conversation log 324 (FIG. 3C)for playback, sequences of operations performed in short periods of timeare merged. As noted above, a conversation log record 385 can include alist of authors 390 identifying multiple authors of a change to theconversation state when more than one author is editing the sameconversation at the same time or during overlapping times. Furthermore,when there are no conflicts between participants, entire sequences ofediting by a participant, from the start of an edit sequence until theuser selects the “done” icon or button, are merged into a single editsequence for storage in a single conversation log record 385 (FIG. 3C).

FIG. 12 illustrates a process diagram showing the application ofconcurrency control between a plurality of potentially conflicting editsreceived from two participants. The example illustrated in FIG. 12 showstransformation operations of ASCII text including XML tags and content.Operations are performed at a first participant (client) and at a secondparticipant (client).

A first sequence of edits to a respective content unit of theconversation is received from a first participant of the conversation,and the first sequence of edits is converted into a first mergedsequence of edits (1212). A second sequence of edits to a respectivecontent unit of the conversation is received from a second participantof the conversation, and the second sequence of edits is converted intoa second merged sequence (1216).

The first merged sequence of edits (1212) is transformed to produce afirst transformed sequence of edits (1232), and the second mergedsequence is transformed to produce a second transformed sequence ofedits (1222). The first transformed sequence of edits (1232) is sent tothe second participant, and the second transformed sequence of edits(1222) is sent to the first participant. At the first client, the firstmerged sequence (1212) is applied to an initial conversation state D1 toproduce an intermediate conversation state D2, and then the secondtransformed sequence of edits (1222) is applied to the conversationstate D2 to produce a new conversation state D4. At the second client,the second merged sequence of edits (1216) is applied to the initialconversation state D1 to produce an intermediate conversation state D3,and then the first transformed sequence of edits (1232) is applied tothe intermediate conversation state D3 to produce the same newconversation state D4 as produced at the first client. Thus, thetransformed sequences of edits, 1232 and 1222, are generated so thatwhen they are applied to the conversation state after the application oflocally made edits (corresponding to merged sequence of edits for thatclient), the conversation state in both clients converges to aconsistent state.

In the example of FIG. 12, each ASCII text character has a size of one,and each starting and ending XML tag has a size of one. In the exampleof FIG. 12, “delete text” refers to a text deletion component of theoperation, and “delete element” refers to an element deletion operation.The number accompanying a text or element deletion operation refers tothe size of the element deletion. Both “insert element” is used to addXML tags to a conversation unit, and “insert text” is used to inserttext. Transformations of merged sequences of content update operations(edits) take into account the position of each operation in theconversation unit, and also take into account duplicate operations(e.g., completing operations that delete the same text), or moregenerally operations that render other competing operations moot).

The initial conversation state D1 1210 comprises a first string:

-   -   D1=<example>abcdefg</example>

The second (or revised) conversation state D4 1240 comprises a secondstring:

-   -   D4=<example>a<tagName attr1=“value1”        attr2=“value2”>A<nested>B</nested>C</tagName>fg</example>

Intermediate conversation state D2 1220 comprises a third string:

-   -   D2=<example>ab<tagName attr1=“value1”        attr2=“value2”>A<nested>B</nested>C</tagName>fg</example>

Intermediate conversation state D3 1230 comprises a fourth string:

-   -   D3=<example>aefg</example>

The first merged sequence of edits 1212 provides the following edits:

-   -   skip 3    -   insert element start with tag name “tagName” and    -   attributes [attr1=“value1”, attr2=“value2”]    -   insert text “A”    -   insert element start with tag name “nested” and attributes    -   insert text “B”    -   insert element end    -   insert text “C”    -   insert element end    -   delete text 3 (e.g., text cde)

When the first merged sequence of edits 1212 is applied to the initialconversation state D1 1210, the result is intermediate conversationstate D2 1220, described above. A dotted box 1214 indicates the portionof state D2 in which changes were made to D1 by the first mergedsequence of edits 1212.

The second transformed sequence of edits 1222 provides the followingedits:

-   -   skip 2    -   delete text 1

The second transformed sequence of edits 1222 deletes the letter “b”1224 from the intermediate conversation state D2. The result of thisoperation is the second (or revised) conversation state D4 1240.

The second merged sequence of edits 1216 provides the following edits:

-   -   skip 2    -   delete text 3 (e.g., delete “bcd”)

The second merged sequence of edits 1216 deletes the letters “bcd” fromthe first conversation state D1. The result of applying the secondmerged sequence of edits 1216 to the first conversation state D1 is theintermediate conversation state D3 1230.

The first transformed sequence of edits 1232 provides the followingedits:

-   -   skip 2    -   insert element start with tag name “tagName” and attributes        [attr1=“value1”, attr2=“value2”]    -   insert text “A”    -   insert element start with tag name “nested” and attributes    -   insert text “B”    -   insert element end    -   insert text “C”    -   insert element end    -   delete text 1

The first transformed sequence of edits 1232 changes the intermediateconversation state D3 by adding the material indicated by the dottedline 1234 on FIG. 12. The result of this operation is the secondconversation state D4.

It is noted that the merging of edit sequences makes the detection ofconflicting edits (by different users) easier, thereby reducing theamount of computational resources needed for concurrency control.Conflicting edits are detected, for example, when the transformation ofa merged sequence of edits would change the position of at least oneedit operation. Conflicting edits are also detected when first andsecond merged sequences of edits (by two distinct participants) includeoverlapping delete operations. Transforming a merged sequence of editsfor which there is an overlapping delete operation (i.e., overlappingwith edit operations by another participant) produces a transformeddelete operation that deletes fewer elements of the respective contentunit than the respective delete operation of the merged sequence ofedits.

In some embodiments, when first and second merged sequences of operationinclude overlapping operations, including a redundant operation, thefirst transformed sequence of edits does not include the redundantoperation.

In some embodiments, distinct conversation (or content unit) versionnumbers are associated with the state of a respective conversation (orcontent unit) before and after each merged sequence of edit operations.Similarly, distinct version numbers are associated with the state of arespective conversation (or content unit) before and after eachtransformed sequence of edit operations. In some embodiments, distincttimestamps are associated with each distinct version number of theconversation (or content unit).

FIG. 13 illustrates a sequence of separate edit operations to a contentunit received from a first participant and a sequence of separate editoperations received from a second participant in a conversation.

A starting point for this sequence is a first content unit state 1310,comprising the text “ABCDEFG”. A first sequence of edits is receivedfrom a first participant, including:

-   -   1316: insert “X” at 6, resulting in text ABCDEFXG    -   1318: insert “Y” at 1, resulting in text AYBCDEFXG    -   1350: delete 3-5, resulting in text AYBEFXG

A second transformed sequence of edits is received from the secondparticipant and applied at the first participant, including:

-   -   1352: delete 3-4, resulting in text AYBFXG    -   1354: insert “M” at 5, resulting in text AYBFXMG    -   1356: insert “N” at 3, resulting in text AYBNFXMG.        This is the final content unit state 1370.

Again, referring to the starting state 1310, comprising the text“ABCDEFG”, a second sequence of edits is received from a secondparticipant, including

-   -   1312: delete 3-5, resulting in text ABCFG    -   1314: insert “M” at 4, resulting in text ABCFMG    -   1330: insert “N” at 3, resulting in text ABCNFMG

A first transformed sequence of edits is received from the firstparticipant and applied at the second participant, including:

-   -   1332: insert “X” at 5, resulting in text ABCNFXMG    -   1334: insert “Y” at 1, resulting in text AYBCNFXMG    -   1336: delete 3-5, resulting in text AYBNFXMG.        This is the final content unit state 1370, and is the same        content unit state as achieved using the first sequence of edits        and the second transformed sequence of edits.

Since there are a plurality of separate edits, there are also aplurality of transforms (indicated by the plurality of arrows/paths fromcontent unit state 1310 to content unit state 1370). In this embodiment,each transform has to be calculated for each path, which consumesprocessor resources and takes time.

FIG. 14 illustrates 1400 a sequence of merged edit operations to acontent unit received from a first participant and a sequence of mergededit operations received from a second participant in a conversation,and transforms thereon.

A starting point for this sequence is a first content unit state 1410,comprising the text “ABCDEFG” and corresponding to the starting contentunit state 1310 of FIG. 13.

A first merged sequence of edits is received from a first participant,including:

-   -   1416: skip 1, insert “Y”, skip 1, delete 2, skip 2, insert X,        resulting in text AYBEFXG, content unit state 1450.

A second transformed merged sequence of edits is received from thesecond participant and applied at the first participant, including:

-   -   1952: skip 3, delete 1, insert “N”, skip 2, insert M, resulting        in text AYBNFXMG, end point 1470.

Again referring to the starting content unit state 1410, comprising thetext “ABCDEFG”, a second merged sequence of edits is received from asecond participant, including:

-   -   1912: skip 3, delete 2, insert “N”, skip 1, insert “M”,        resulting in text ABCNFMG, content unit state 1430.

A first transformed merged sequence of edits is received from the firstparticipant and applied at the second participant, including:

-   -   1432: skip 1, insert “Y”, skip 1, delete 1, skip 2, insert “X”,        resulting in text AYBNFXMG, which is the final content unit        state 1470.        This is the final content unit state 1470 as the state achieved        by applying the first merged sequence of edits and the second        transformed merged sequence of edits.

Since the individual edits (e.g., as in FIG. 13) are merged into asequence of edits in FIG. 14, there are fewer transforms required usingthe embodiment of FIG. 14 versus that of FIG. 13 (indicated by the pairof arrows/paths from point 1310 to point 1370). In this embodiment, onetransform has to be calculated for each path, which is a lowerprocessing burden than the embodiment of FIG. 13. The embodiment of FIG.14, using merged sequences of edits, thus provides advantages of areduced calculation requirement.

Other Applications

Another application that may be associated with the server hosting theconversation includes a contextual spell checker and correctionapplication. Such an application can be used to find commonmisspellings, and to disambiguate intentionally defined words. Such anapplication may use an error model to determine if an work is spelled orused correctly. The model may find common errors based on letterreversal, phonetic similarity, location in a conversation or letter, orusing other means. The application may provide on-the-fly, context basedtext correction. In some embodiments, the application provides auser-specific overlay of words that a user frequently uses or that theuser has defined. In some embodiments, the application may insert a tagwith a suggestion for a word that it considers to be incorrectlyspelled, such that any participant (not just the author) can address andcorrect the word, if necessary.

Another application that may be associated with the server hosting theconversation includes a contextual name display, using context-dependentdisambiguation. In some embodiments, this disambiguation may providespace efficiency when displaying names. For example, a close friend orwork colleague may be displayed using a first name only or a picture,whereas a stranger may be displayed with full name, title, etc. A set ofrules (defined by the system or by the user or both) may be used todetermine who to display and in what manner.

Another application that may be associated with the server hosting theconversation includes a language translation (machine translation)application. This machine translation application may use the spellchecking and/or a context sensitive dictionary to translate betweenlanguages.

In some embodiments, these (and other) applications use an applicationprotocol interface (API) to interact with the server hosting theconversation. In some embodiments, the application allows a participantto reserve a namespace for that participant's personal applications,which the participant may share with other participants.

FIG. 16 is a block diagram of a distributed client-server computingsystem 2000 including a conversation server 700 according to someembodiments of the invention. The conversation server 700 is connectedto a plurality of conversation clients 800 and third party webservers2002 through one or more communication networks 120. A third partywebserver 2002 may include a collection of web pages 2004 associatedwith a domain name on the Internet (e.g., a website).

The conversation client 800 (sometimes called a “client system,” or“client device” or “client computer”) may be any computer or devicethrough which a user of the conversation client 800 can submit servicerequests to and receive search results or other services from theconversation server 700. Examples of conversation clients 800 include,without limitation, desktop computers, laptop computers, tabletcomputers, mobile devices such as mobile phones, personal digitalassistants, set-top boxes, or any combination of the above. A respectiveconversation client 800 may contain at least one client application 814for submitting requests to the conversation server 700. For example, theclient application 814 can be a web browser or other type of applicationthat permits a user to search for, browse, and/or use information (e.g.,web pages and web services) that is accessible through communicationnetwork 120. In some embodiments, the conversation client 800 includesone or more client assistants 2008. The client assistant 2008 can be asoftware application that performs one or more tasks related toassisting a user's activities with respect to the client application 814and/or other applications. For example, the client assistant 2008 mayassist a user at the conversation client 800 with browsing information(e.g., files) hosted by a third party webserver 2002, processinginformation (e.g., conversations or search results) received from theconversation server 700, and monitoring the user's activities on thesearch results. In some embodiments the client assistant 2008 isembedded in one or more web pages (e.g., a search results web page) orother documents downloaded from the conversation server 700. In someembodiments, the client assistant 2008 is a part of the clientapplication 814 (e.g., a plug-in of a web browser).

The communication network(s) 120 can be any wired or wireless local areanetwork (LAN) and/or wide area network (WAN), such as an intranet, anextranet, the Internet, or a combination of such networks. In someembodiments, the communication network 120 uses the HyperText TransportProtocol (HTTP) and the Transmission Control Protocol/Internet Protocol(TCP/IP) to transport information between different networks. The HTTPpermits client devices to access various information items available onthe Internet via the communication network 120. The various embodimentsof the invention, however, are not limited to the use of any particularprotocol.

In some embodiments, the conversation server 700 includes a front endserver 2006, an entity profile generator 760, a conversation profilegenerator 762, a profile comparer 764, a suggestion generator 766, aconversation database 726, and a user profile database 768. Optionally,the conversation server 700 also includes one or more of a conversationprofile database 770, and profile generation policies 772.

The front end server 2006 is configured to receive data from aconversation client 800. In some embodiments the data is a conversation,and is stored in a conversation database 726. Conversations from theconversation database 726 are accessed by the entity profile generator760 to generate entity profiles based at least in part on theconversations in accordance with profile generation policies 772. Theentity profiles are stored in a user profile database 768.

In some embodiments the data is a request that is received fromconversation client 800, and the request is sent from the front endserver 2006 to the conversation profile generator 762. The conversationprofile generator 762 analyzes the conversation and generates aconversation profile based at least in part on the receivedconversation. In some embodiments, the conversation is stored in theconversation database 726 and the conversation profile generator 762accesses the conversation from the conversation database 726. In someembodiments the conversation profile is sent from the conversationprofile generator 762 directly to the profile comparer 764, where theprofile comparer 764 compares the conversation profile with entityprofiles from the user profile database 768. In other embodiments, theconversation profile is stored in the conversation profile database 770,and the profile comparer 764 retrieves conversation profiles from theconversation profile database 770 and entity profiles from the userprofile database 768 and then compares the conversation profile tovarious ones of the entity profiles. In some embodiments, theconversation profile database 770 is a cache that stores recentlygenerated conversation profiles. In these embodiments, a respectiveconversation profile is purged when there are no active participants inthe corresponding conversation, and is replaced with an updated profilewhen the amount of change to the conversation in the conversation, sincethe conversation profile was last generated, meets one or morepredefined criteria. Examples of the predefined criteria includecriteria concerning the quantity or percentage of conversation contentthat changes, criteria concerning the deletion of terms in the profile,and/or criteria concerning the additional or removal of participants,tags, attachments, or any other feature(s) relevant to the conversationprofile.

The suggestion generator 766 receives the comparisons (e.g., similarityscores) from the profile comparer 764 and generates suggestionsincluding at least some of the entities associated with the entityprofiles. It should be understood that, in some circumstances nosuggestions are generated for a conversation. For example, if all of theterms that have been added to the conversation are terms that are notused to create entity profiles (e.g., terms that have been deemed to benon-predictive, such as “noise words” like “the,” “of,” “and,” etc.),any comparison of the conversation profile with any entity profile willresult in a score of zero. The front end server 2006 receives thesuggestions and provides the suggestions to the conversation client 800associated with the received data (e.g., the original request forsuggestions) through the communication network 120.

It should be understood that while a system 2000 may have a singleconversation server 700, in other embodiments the system 2000 may havemultiple conversation servers 700. For example, as described in greaterdetail above with reference to FIG. 1, multiple conversation servers 130may be hosted by different service providers, such as providers 116-Aand 116-B respectively. In some embodiments, the providers are internetservice providers (ISPs) providing a conversation service. Alternately,some or all of the providers may be dedicated conversation providers.When the system 100 includes multiple conversation servers 130, theconversation servers 130 may be coupled together directly, or by a localarea network (LAN), or via the network 120.

Attention is now directed towards FIG. 17A, which illustrates anoverview of a method for generating entity suggestions in accordancewith some embodiments. In some embodiments, conversation activity (2010)occurs, as described in greater detail above with reference to FIGS.5A-5E. In accordance with some embodiments an entity is a participantidentifier (e.g., an account username, an email address, an instantmessenger screen name, a phone number, etc.), a tag (e.g., human editedmetadata associated with a conversation that is visible to allparticipants in the conversation), or a label (e.g., a folder orattribute associated with a conversation on a per user basis and is onlyvisible to the user who associated the label with the conversation).

It should be understood that this conversation activity may involve oneor more clients and one or more servers exchanging data to create aplurality of conversations. In some embodiments a plurality ofconversations associated with a user (e.g., conversations in which theuser is a participant) are stored (2012) at the conversation server 700.The conversation server 700 generates (2014) a plurality of entityprofiles for the user, as described in greater detail below withreference to FIG. 17B. In some embodiments, a triggering action isperformed at the client. In some embodiments, the triggering actionincludes the user editing (2016) a conversation (e.g., creating a newconversation, entering or deleting content from an existingconversation, or adding a participant, tag or label to a conversation).In some embodiments the triggering action is an action performed by adifferent user who is also a participant in the conversation. In someembodiments the triggering action is a request (2018) to enter an entityaddition mode (e.g., the user opens an address book panel or pop-upwindow, the user places a cursor in a user interface box for adding atag, label or a contact, or the user adds content to a portion of theconversation associated with a concurrently displayed entity list, andthe entity list is reordered based on the added content).

In some embodiments, the conversation client 800 periodically sendsrequests to the conversation server 700 for entity suggestions, whichare not based on inputs from the user. Similarly, in some embodiments,the conversation server 700 periodically accesses a conversationassociated with the user (e.g., the most recently edited conversationthat is currently active (e.g., displayed in a window) on theconversation client) and generates entity suggestions. Both of theseautomatic suggestion generating methods generate suggestionsperiodically so that fresh suggestions are available to the userimmediately after the user requests a suggestion, rather than requiringprocessing by the conversation server 700 in response to a request fromthe user.

In some embodiments the conversation server 700 accesses (2020) aconversation in which the user is a participant, and obtains (2022) aconversation profile for the conversation. In some embodiments, theaccessed conversation is the conversation that was being edited by theuser or is currently displayed to the user on the conversation client800. In some embodiments, obtaining a conversation profile includesgenerating (2024) the conversation profile for the conversation asdescribed in greater detail below with reference to FIG. 17C.

In some embodiments, the conversation server 700 accesses (2026) aplurality of entity profiles corresponding to the user. In someembodiments, each entity profile corresponds to a respective entity inother conversations in which the user is a participant and is based oncontent in the other conversations. In some embodiments, the entityprofiles include entities that are present in all of the conversations(i.e., including the accessed conversation) in which the user is aparticipant and are based on the content of all of those conversations.For example, a respective conversation is used as a “trainingconversation” in order to create the entity profiles for a particularuser, as described in greater detail below with reference to FIG. 17B.In this example, when the user later returns to view this respectiveconversation, entity suggestions are displayed that are based on thegenerated entity profiles (which are, in turn, based in part on therespective conversation). The conversation server 700 compares (2028) atleast a subset of the entity profiles to the conversation profile toidentify a set of entities having entity profiles that best match theconversation profile, as discussed in greater detail below withreference to FIG. 17D. In some embodiments, the conversation servergenerates (2030) a suggestion including a suggested entity from theidentified set of entities, as described in greater detail below withreference to FIG. 17D. For example, if Anne is creating a newconversation and has not yet selected a participant (e.g., recipient)for the conversation, but begins to write “Hi Barry, Do you still wantto go to Tahoe this . . . ” a generated suggestion may include Barry'scontact information if Anne has created other conversations where Barrywas a participant.

In accordance with some embodiments, the conversation server 700 sends(2032) the suggestion to the client system for display. It should beunderstood that a suggestion may include a single entity, or asuggestion may include a plurality of entities such as a ranked list ofentities (e.g., a ranked list of the most likely contacts to add asparticipants to the conversation or the most likely tags to add asmetadata). The conversation client 800 receives the suggestion anddisplays (2034) the suggestion to the user. If the user selects (2036) asuggested entity, then the conversation client 800 sends to theconversation server a response that identifies the user-selectedsuggested entity. In some embodiments, the conversation server receives(2038) the response from the client system and associates (2040) theuser-selected entity with the conversation (e.g., the user-selectedsuggested entity is associated with the conversation). Continuing theexample from above, Anne begins adding text to the conversation andBarry's contact information (e.g., account name or email address) isdisplayed to Anne at the top of a contact list in the user interfacewhere Anne is editing the conversation. Anne selects Barry to add to theconversation, and the conversation server 700 adds Barry as aparticipant to the conversation.

In some embodiments, the suggested entity is not selected (2042) by theuser, but instead an alternate entity is selected (2044). In this case,the user-selected entity is associated (2040) with the conversation. Ifthe user does not select (2046) an alternate entity, then the methodends (2048). It should be understood that the process of selecting asuggested entity or an alternate entity may be combined into a singlestep, where the user is presented with a plurality of entities includingboth suggested and alternate (e.g., non-suggested) entities and selectsone or more entities from the list. In some embodiments, if the userdoes not select (2046) an alternate entity the process is done (2048).It should be understood that in some embodiments the method shown inFIG. 17A is repeated in response to editing of the conversation by theuser or editing of another conversation in which the user is aparticipant. Similarly, in some embodiments, the method is repeated inresponse to editing or input by participants in the conversation otherthan the user.

Attention is now directed towards FIG. 17B, which illustrates a methodfor generating (2014) an entity profile in accordance with someembodiments. In some embodiments, as a preliminary step of generating anentity profile, the conversation server 700 analyzes (2050) a pluralityof conversations of the user (i.e., historical conversations, stored inthe conversation database) to identify a plurality of predictive termsfor use in generating the entity profile, as described in greater detailbelow with reference to FIG. 17E. In some embodiments, the plurality ofconversations used by the conversation server to generate an entityprofile are batches of archived conversations, rather than activeconversations that are available “on-line” in the running conversationsystem (e.g., the “live” conversations that can be concurrently editedby a plurality of participants). In other words, the conversation systemcopies the content of a plurality of conversations from the runningconversation (e.g., a “snapshot” of the conversations in which the useris a participant) to a separate data structure and generates entityprofiles based on these archived conversations. While using batches ofarchived conversations to generate entity profiles introduces thepossibility that some of the conversations will be out of date (e.g.,because some of those conversations may have been revised after beingarchived), it allows the entity profile generation to be performed insuch a way that it does not affect the performance of the runningconversation system.

In some embodiments, a term is a word in a conversation. In someembodiments a term is an entity such as a tag or a label. However, itshould be understood, that as used herein the word “term” does notnecessarily refer exclusively to a word or explicit text token (e.g., atag or a label) but may be an aspect of the conversation such as whichother users are already participants in a conversation or a type ofcontent that is attached to the conversation. In some embodiments, asingle term includes a first word and a second word, wherein the firstword is a synonym of the second word.

In accordance with some embodiments, the conversation server 700 selects(2052) an entity associated with the user, selects (2054) a conversationassociated with the entity, selects (2056) a predictive term in theconversation and counts (2058) the occurrences of the predictive term inthe conversation. It should be understood that the predictive terms maybe selected from the plurality of predictive terms previously identifiedby the conversation server 700. In some embodiments, the occurrences ofthe predictive term in the conversation are weighted (2060) based on theinternal structure of the conversation, as described below in greaterdetail with reference to FIG. 17F.

In some embodiments, the count of occurrences of a predictive term in aconversation is discounted (2061) (e.g., logarithmic discounting), sothat the first occurrence (or the first N occurrences) of a term in aconversation has a greater weight than the subsequent occurrences of theterm. In some embodiments, this discounting helps to prevent thefrequent occurrence of a single term in a conversation fromdisproportionately skewing the comparison of a conversation profile toan entity profile. In some embodiments the discounted term count isadjusted (2062) using a term weight from the user profile. In someembodiments, the term weights are user-specific term weights (e.g., termweights 2240 in a user profile 2230-2 as described in greater detailbelow with reference to FIG. 18B). In other words, the term weight is acontext-independent weight that is indicative of the importance of theterm to the user. For example, a term that occurs frequently inconversations in which the user is a participant will have a higherweight than a term that occurs less frequently in conversations in whichthe user is a participant. In some embodiments an inverse documentfrequency metric is used, so that the term weight is based on (e.g.,inversely proportional to, or inversely related to) the percentage ofthe user's conversations in which the term appears (as opposed to thenumber of times that the term is used in all of the conversationsassociated with the user). In some embodiments the term weight is basedon the number of times that the term is used in at least a subset of theconversations associated with the user.

Consequently, in accordance with some embodiments, the entity profilesfor each user are individualized to that particular user in at least twoways. First, an entity profile is explicitly generated based on terms inthe conversations associated with the entity in which the user is aparticipant. Second, the entity profile is individualized to theparticular user, by adjusting the elements of the entity profile basedon user-specific term weights. It should be understood that, in someembodiments, the user-specific term weights are generated based on aplurality of conversations in which the user is a participant, at leasta subset of which are not associated with the entity. Thus, in someembodiments, the term weights include contributions from bothconversations that are associated with the entity (e.g., via analyzingthe terms in conversations associated with the entity as illustrated inFIG. 17B) and also from conversations that are not associated with theentity (e.g., via the user-specific term weights). As a result, in theseembodiments, the entity profile is determined based at least in part onconversations that are not associated with the entity. For example, ifthe user frequently uses the term “email” in all of his conversations,that term will have a low user-specific term weight compared to a normalterm weight, and thus the term “email” will have reduced significance inan entity profile that includes the term as compared with terms thathave a normal term weight. In contrast, if the user only uses the term“Tahoe” in conversations that are associated with the entity “travel”then the term will have a high user-specific term weight compared to anormal term weight, and thus the term “Tahoe” will have increasedsignificance in an entity profile that includes the term as comparedwith terms that have a normal term weight.

After the occurrences of the predictive term in the conversation havebeen counted (optionally with weighting as described above), theconversation server 700 checks to determine whether there are morepredictive terms in the conversation to count (e.g., the conversationserver counts the occurrence of the term “Tahoe” and then counts theoccurrences of the term “pizza”). If there are (2063) more terms, theconversation server 700 selects one of those terms (e.g., “pizza”) andrepeats the process described above. In some embodiments, if there areno (2064) uncounted predictive terms in the selected conversation, thenthe conversation server adjusts (2066) the contributions to the entityprofile for the selected conversation (e.g., discounting by the age ofthe conversation or the length of the conversation). In someembodiments, conversations are progressively degraded as they age so asto reduce their influence in the generation of the entity profile. Forexample, a conversation that is one week old will be adjusted so that itinfluences the entity profile half as much as a conversation that is oneday old, and a conversation that is one month old will be adjusted sothat it influences the entity profile one eighth as much as aconversation that is one day old. In another example, the weight of aconversation is reduced by half every N (e.g., ten) days.

In some embodiments, the conversation server 700 determines (2068)whether there are any additional conversations that are associated withthe entity. If there are (2068) more conversations, then theconversation server 700 selects (2054) a new conversation associatedwith the entity and repeats the process described above. In someembodiments, if there are not (2070) any more conversations, then theconversation server 700 normalizes the entity profile. In someembodiments the entity profile is normalized such that the sum of thesquare of the elements of the entity profile is equal to a fixed value(e.g., 1). In other words, if the entity profile is a vector in termspace, where term space includes the predictive terms for a particularuser (as described in greater detail below with reference to FIG. 17E),an L2 normalization can be used to normalize the entity vector (e.g.,the elements of the vector are divided by the magnitude of the vector,so as to produce a vector with a length of one in term space).

The conversation server 700 stores (2074) the entity profile in the userprofile database, as described in greater detail below with reference toFIG. 18A. The conversation server 700 determines whether there are anymore entities for which a profile should be generated. If there are(2076) more entities for which the conversation server 700 determinesthat a profile should be generated, then the conversation server 700selects (2052) one of these entities and repeats the process describedabove for generating an entity profile. If there are not (2078) any moreentities to generate a profile for, then the conversation is done (2080)generating entity profiles.

In some embodiments, the entity profiles for a respective user areperiodically rebuilt from scratch on a predetermined schedule that isset in accordance with profile generation policies (e.g., 772 in FIG.16). In some embodiments, the profile generation policies also includeinformation indicative of the number of terms to use to generate entityprofiles, and/or the number of entity profiles to generate. In someembodiments the predetermined schedule is based on how often the entityprofiles are likely to change. If changes are more frequent, then theentity profiles are re-generated more frequently, while if changes areless frequent, then the entity profiles are re-generated lessfrequently. In another example, a new user will typically have morefrequent updates than a user who has been using the conversation systemfor a long time. Similarly, a user with a high level of new activity(e.g., a large number of new conversations or deleted conversations)will be scheduled to have her entity profiles re-generated. In someembodiments, all of the entity profiles for a particular user arere-generated at the same time (e.g., in response to the same initiatingevent).

Attention is now directed towards FIG. 17C which illustrates a methodfor generating (2024) a conversation profile in accordance with someembodiments. The conversation profile is based on information includingcontent of the conversation. In some embodiments, the conversationprofile is also based on user-specific term weights for at least aplurality of terms in the content of the conversation. The conversationserver 700 accesses (2082) a currently active conversation in which theuser is a participant (e.g., the conversation that was edited by theuser (2016 in FIG. 17A). In some embodiments the conversation serverselects (2084) a predictive term in the conversation. In someembodiments, the predictive term is selected from a plurality ofpredictive terms (e.g., a subset of terms in the conversationsassociated with the user) that are identified based on predefinedcriteria, as described in greater detail below with reference to FIG.17E.

In some embodiments the conversation server 700 counts (2086) theoccurrences of the predictive term in the conversation. In someembodiments, the occurrences of the predictive term are weighted (2087)based on internal structure of the conversation as discussed in greaterdetail below with reference to FIG. 17F. In some embodiments, the termcount is discounted (2088) so that the first occurrence of the term isgiven greater weight than subsequent occurrences of the term (e.g.,logarithmic discounting), as described in greater detail below withreference to FIG. 18B. In some embodiments the discounted term count isadjusted (2090) using a term weight that is stored in the user profile.The term weight is a context-independent weight that is indicative ofthe importance of the term to the user. In other words, a term thatoccurs frequently in conversations in which the user is a participantwill have a higher weight than a term that occurs less frequently inconversations in which the user is a participant. In some embodiments aninverse document frequency metric is used, so that the term weight isbased on (e.g., inversely proportional to, or inversely related to) thepercentage of the user's conversations in which the term appears (asopposed to the number of times that the term is used in all of theconversations associated with the user). In some embodiments the termweight is based on the number of times that the term is used in at leasta subset of the conversations associated with the user.

It should be understood that, in accordance with some embodiments, theseterm weights are user-specific term weights. In other words, a pluralityof participants each have respective user profiles, and have respectiveuser-specific term weights for one or more terms in the user profile.Thus, in some embodiments, the conversation has at least a secondparticipant in addition to the user, and the second participant has asecond conversation profile for the conversation that is based onrespective term weights, for a plurality of respective terms, specificto the second participant. Additionally, it should be understood thatany number of participants could be associated with a conversation, eachhaving a respective set of user-specific term weights that are stored ina user profile for the user. Consequently, when conversation profilesare generated for the conversation for multiple different participants,a first conversation profile for a first participant is different from asecond conversation profile for a second participant, because the firstconversation profile would be based on a first set of user-specific termweights while the second conversation profile would be based on a secondset of user-specific term weights that are distinct from the first setof user-specific term weights.

Additionally, in some embodiments, the predictive terms for the firstuser (e.g., as selected in accordance with FIG. 17E) are distinct fromthe predictive terms for the second user. In this embodiment, theconversation profile for the first user would be distinct from theconversation profile for the second user not only because theuser-specific term weights for the first user are distinct from theuser-specific term weights for the second user, but also because theconversation profile for the first user would includes terms from theconversation profile that are not included in the conversation profilefor the second user. Consequently, although the first user and thesecond user are both participants in the same conversation, which has asingle set of content, the conversation profile for the first user isgenerated based at least in part on user-specific criteria that isspecific to the first user, and thus is distinct from the conversationprofile for the second user, which is generated based at least in parton user-specific criteria that is specific to the second user.

After discounting the term count and adjusting the discounted term countfor the selected term, if the conversation server 700 server determinesthat there are (2092) additional predictive terms to evaluate, then theconversation server 700 selects (2084) one of the remaining predictiveterms and repeats the process described above. However, if theconversation server 700 determines that there are not (2094) anyadditional predictive terms in the conversation for which occurrencesare to be counted, then the conversation server normalizes (2096) theconversation profile. In some embodiments the conversation profile isnormalized such that the sum of the squared elements of the conversationprofile equal a fixed value. In other words, if the conversation profileis a vector in term space, where term space includes the predictiveterms discussed above, an L2 normalization can be used to normalize theconversation vector (e.g., the vector are divided by the magnitude ofthe vector, so as to produce a vector with a length of one in termspace).

In some embodiments the conversation profile is stored (2098) in theconversation profile database as described in greater detail below withreference to FIG. 18C. It should be understood that in some embodiments,the conversation profile is cached in a cache rather than being storedin a database. Alternatively, in some embodiments, the conversationprofile is generated on-the-fly for use by the conversation server 700,and when (and if) the conversation profile is needed again, theconversation server 700 generates a new conversation profile. Generatingconversation profiles on-the-fly is particularly important in caseswhere the conversation is being actively edited by the user while theentity suggestions are concurrently being generated. As the user orother participants edit the conversation, the content of theconversation may change dramatically, and thus the old conversationprofiles are obsolete and are more likely to return inaccurate entitysuggestions. After determining that there are no more predictive termsto select (2094) and (optionally) storing the conversation profile(2098), the server is done (2100) generating a conversation profile.

Attention is now directed towards FIG. 17D which illustrates a methodfor comparing at least a subset of entity profiles to the conversationprofile. In some embodiments the conversation server 700 obtains (2102)the conversation profile. In some embodiments, the conversation serverselects (2104) an entity profile (for a respective entity) that includesat least one term in the conversation. For example, if the entityprofile for “Barry” does not include any of the terms in a conversationthat Anne is editing, the entity profile for “Barry” will not beselected for comparison.

In some embodiments, the conversation server 700 calculates (2106) asimilarity score between the entity profile and the conversationprofile. In some embodiments, the conversation profile and the entityprofile each include a plurality of terms. As described above withreference to FIG. 17B, the entity profile has a plurality of elements,each element associated with a respective term and having a value thatcorresponds to a number of instances of the respective term in the setof conversations that are associated with both the user and the entity.Similarly, the conversation profile has a plurality of elements, whereeach element in the conversation profile is associated with a respectiveterm and corresponds to a number of instances of the respective term inthe conversation, as described in greater detail above with reference toFIG. 17C. In some embodiments, the entity profile and the conversationprofile can each be treated as a vector in term space, where each termis a dimension of the term space, and the term space includes all of thepredictive terms identified by the conversation server 700, as describedin greater detail below with reference to FIG. 17E. In this embodiment,calculating (2106) the similarity score between the entity profile andthe conversation profile includes calculating (2110) a dot product ofthe entity vector of the respective entity profile with the conversationvector of the conversation profile (i.e., the sum of the term-wiseproducts of the elements of two vectors). While the illustrativeexamples use a particular technique for calculating the similarityscore, it should be understood that other techniques for comparingvectors (such as cosine similarity) may be used in addition to or as analternative to the specifically disclosed techniques.

In some embodiments the similarity score is stored (2112) at theconversation server. If there are (2114) additional entities with entityprofiles to compare with the conversation profile, then the conversationserver 700 selects (2104) one of the remaining entity profiles andrepeats the process described above. If there are not (2116) any moreentity profiles to compare with the conversation profile, then theprocess is done (2118).

In an alternative embodiment, the conversation server 700 identifies oneor more of the predictive terms in the conversation vector. For eachpredictive term in the conversation vector, the conversation serveridentifies the entities with entity profiles that include the term. Insome embodiments the entity profiles are grouped by the terms that theycontain to increase the speed and efficiency of this identificationprocess. The conversation server then combines (e.g., multiplies) theelement in the conversation profile with an element in each of theentity profiles that corresponds to the same term and stores the resultfor each entity profile as a comparison value associated with eachentity. Once this process has been completed for each entity profilethat contains an element associated with the predictive term, theconversation server iterates to a next predictive term in theconversation profile. For the next predictive term, the same process isto combine the conversation profile element with the correspondingentity profile element of the entity profiles that correspond to thesame term. The resulting comparison value is added to a running totalfor the entity profile. Once all of the predictive terms in theconversation profile have been iterated through by the conversationserver 700, the conversation server 700 determines rankings of theentities based at least in part on the total of the comparison valuesfor each of the entities. It should be noted that this process producesa result that is equivalent to the computation of a dot product betweeneach of the entity profiles and the conversation profile (where theentity profiles and conversation profile are vectors in term space),however the process described in this paragraph is more computationallyefficient, because entity profiles that share no predictive terms withthe conversation profile are not compared with the conversation profile,and because only the elements of the entity profiles that match elementsof the conversation profile are used.

In some embodiments, after the subset of entity profiles have beencompared (2028) with the conversation profile, the conversation server700 generates (2030) a suggestion including a suggested entity from theidentified set of entities. In some embodiment, entities that arealready present in the conversation are excluded (2120) fromconsideration. In some embodiments, generating the suggestion includesranking (2122) the entities based on the computed similarity scores. Forexample, if the conversation profile for Anne's conversation and theentity profile for “Barry” have the highest similarity score, while theconversation profile and the entity profile for “Carrie” have the secondhighest similarity score, and the conversation profile and the entityprofile for “Tahoe” have the third highest score, then the entities willbe ranked as follows: 1) Barry, 2) Carrie, 3) Tahoe.

In some embodiments, the rank is also determined at least in part by anon-similarity score component (e.g., a non-contextual affinity score ofthe entity.). Thus, continuing the example above, if Anne has been aparticipant (e.g., participated) in 10 conversations with Barry, 1conversation with Carrie and 15 conversations with the tag “Tahoe,” thenthe entities may be ranked as follows: 1) Barry, 2) Tahoe, 3) Carrie. Inthis example, the affinity score is based on the frequency of use of theentity by the user and the contextual score is based on the comparisonbetween the entity profile and the conversation profile. In the example,these two scores are combined to determine the overall rank of theentity.

In some embodiments, the conversation server suggests (2126) a subset ofthe entities (e.g., Barry, Tahoe and Carrie) based on the comparison. Insome embodiments the subset of the entities includes suggesting (2128)the top N entities from the ranked list of entities. Returning to theexample from above, Anne's list of entities may also include additionallabels/folders (e.g., “family,” “work,”), contacts (“Edgar,” “Frank,”and “Susan”) and tags (e.g., “California,” “Fishing”), however theseentities are not included in the suggested subset of entities, becausethey are not in the top N entities (e.g., the top three entities). Insome embodiments entities that are already present in the conversationare included in the initial ranking but are excluded from thesuggestions. Continuing the example from above, if only the top threeentities are to be suggested and Barry is already a participant in theconversation, then Tahoe, Carrie and a fourth ranked entity (e.g.,“family”) are suggested, rather than suggesting Barry, Tahoe and Carrie.While the foregoing example is given with respect to entities thatinclude both contacts and categorization entities (e.g., labels, foldersand tags), it should be understood that in some embodiments, theentities include only participants (e.g., contacts and/or automatedparticipants), while in other embodiments the entities include onlycategorization entities such as labels, folders and tags.

In some embodiments, the ranked list of suggested entities is a contactlist displayed on the side of a user interface (e.g., a web-basedcommunication program). In this embodiment, displaying the suggestionsmay include reordering the list of contacts in the contact list or in anaddress book.

Attention is now directed towards FIG. 17E which illustrates a methodfor identifying (2050) a plurality of predictive terms for a particularuser (or user account) in accordance with some embodiments. In someembodiments a term is relevant if it is highly predictive of whether arespective entity should be suggested for a conversation (e.g., whetherthe term is highly relevant to the prediction of whether a user willchoose to associate the entity with the conversation). In other words,in some embodiments, generating the entity profile for a respectiveentity includes considering only a subset of the content of therespective conversation, wherein the subset is selected based onpredefined criteria.

In some embodiments, as a preliminary step the conversation server 700identifies (2130) entities in the conversations associated with the user(i.e., entities in historical conversations, stored in the conversationdatabase, in which the user is a participant). In some embodiments theidentified entities include one or more contacts (2132). In some otherembodiments, the identified entities include categorization entities(2133) such as a label/folder (2134) and/or user created metadata suchas a tag (2136). In other words, in these embodiments, the identifiedentities are metadata that is used to sort and categorize conversationsand do not include contacts or participants in the conversation. In someother embodiments, the identified entities include both contacts andcategorization entities. In some embodiments the conversation serverpreselects (2138) a subset of the entities based on one or more of thefollowing criteria: the entity occurs (2140) more than a minimum numberof times (e.g., Barry is a contact in at least two conversationsassociated with Anne), the entity occurs (2142) in more than a thresholdpercentage of conversations (e.g., Barry is a contact in at least 5% ofthe conversations associated with Anne), and/or the entity is in (2144)the top N most frequently used entities (e.g., Barry is one of the top100 participants in conversations associated with Anne). In someembodiments, this preselecting process is used to improve the accuracyof entity suggestions by identifying (or excluding) entities for whichpredictions are likely to be inaccurate. For example, this process helpsto remove any entities for which there is not sufficient informationabout the entity to accurately predict when the user is likely to chooseto associate the entity with a conversation.

In some embodiments, after preselecting the subset of entities, theconversation server 700 evaluates the frequency of use of the selectedentities by the user. In some embodiments this frequency of use ofselected entities is evaluated based on whether the entity is associatedwith a conversation rather than the number of occurrences of the entityin the conversation. The result value, sometimes called an affinityscore, is a measure of the importance of the entity to the user. Inother words, an entity that is frequently used by the user is morelikely to be the entity that the user would like to associate with aconversation. Thus, a frequently used entity is given a higher affinityscore than a less frequently used entity. In some embodiments, theaffinity score for each entity is based on the fraction of totalconversations where the entity is present. In some embodiments theaffinity score is based on the user's implicit social graph. In someembodiments, the affinity score is discounted exponentially in order toreduce the effect of the affinity scores on the selection of entitysuggestions. In one example, the affinity score is set equal to thesquare root of the percentage of conversations in which the entityoccurs. Thus an entity found in 50 percent of all conversations willhave an affinity score of about 0.7, while an entity found in 65 percentof all conversation scores will have an affinity score of about 0.8.Smaller exponents than 0.5, such as 0.3 or 0.2, can be used to furtherdiscount the affinity score.

In accordance with some embodiments, after preselecting the subset ofentities, the conversation server 700 statistically identifies (2148)predictive terms in the conversations associated with the user. Apredictive term for an entity is a term that increases the likelihoodthat the entity will be associated with a conversation that includes thepredictive term (as compared with the likelihood that the entity will beassociated with a conversation that does not include the predictiveterm). It should be understood that the predictiveness of a term is notdirectly correlated with its frequency. For example, the word “and,”will be present in a large percentage of conversations. However the word“and” is not predictive of what entity a user will associate with aconversation. In contrast, the word “Tahoe” is not a commonly used word,and thus it is likely that if the word “Tahoe” is used in aconversation, then the user is more likely to want to include skiingbuddies as contacts, labels such as “vacation,” and tags such as“skiing” or “hiking” with the conversation. However, these preferencesare not explicitly set by a user. Rather, using the method describedherein, predictive terms are statistically identified and then used bythe conversation server 700 to analyze previous conversations, asdescribed in greater detail above with reference to FIG. 17A.

In some embodiments, in order to identify predictive terms, theconversation server 700 determines (2150) a desired number of predictiveterms. This desired number of predictive terms may be a maximum numberthat the conversation server 700 can efficiently store and process forany user (e.g., 1000) or it may be based on the number of termsnecessary to achieve a predefined level of predictiveness. For example,a user who has an account that is used for personal use only may have200 contacts and 100 labels, and in this case, only 400 terms may benecessary to provide the user with accurate entity suggestions. Adifferent user who has an account that is used for business and personaluse may have 1500 contacts and 500 labels and may require 1000 or evenmore terms in order to provide the user with accurate entitysuggestions. Rules for determining the desired number of predictiveterms are included in the profile generation parameters.

In some embodiments, after determining the desired number of predictiveterms, the conversation server 700 selects (2152) a term that appears inthe conversations. In some embodiments the term is (2154) a word in aconversation. In some embodiments, the term is (2156) an entity (e.g., acontact, label, tag, etc., as described previously). In some embodimentsa term is (2158) a type of attachment associated with a conversation(e.g., a pdf, image, text file, spreadsheet, video file, executablefile, slideshow, etc.). The conversation server applies (2160) aheuristic to the selected term to determine some measure of thepredictiveness of the selected term. In some embodiments the heuristicevaluates the term by identifying how predictive the term is for each ofat least a subset of the entity values. A measure of the predictiveness(herein a “heuristic value” for a term) is stored at least temporarily(e.g., in a cache or other data structure). In some embodiments theheuristic is an “information gain” heuristic, which measures thereduction in uncertainty about whether to associate the entity with aconversation when the presence/absence (or the number of instances of)the term in the conversation is known. If uncertainty in associating anentity with a conversation is reduced when the presence/absence (ornumber of instances of) a term is known, then the term is predictive forthat entity.

Once the heuristic has been applied to the term for each of a subset ofthe entities, the conversation server 700 determines if there are moreterms to evaluate for predictiveness. If there are (2162) more term,then the conversation server 700 selects a next term that appears in theconversation and repeats the process described above for the next term.If there are not (2164) any more terms to evaluate for predictiveness,the conversation server 700 selects (2166) the most predictive termsfrom the set of evaluated terms based on the heuristic values. In someembodiments terms are selected based on their overall predictiveness asindicated by the heuristic values. In some embodiments terms areselected based on a plurality of criteria which take into account boththe overall predictiveness of the term and the predictiveness of termsfor less popular entities (i.e., entities which are not the top 50entities most frequently associated with conversations in which the useris a participant). In some embodiments a plurality of heuristic valuesare produced for each term (e.g., one heuristic value for each entitythat is associated with a conversation containing the term). Forexample, it may be advantageous to select predictive terms which arehighly predictive of the tag “skiing,” even though “skiing” is only atag on 1% of the user's conversations, because the presence of a term(e.g., the word “Tahoe”) in a conversation is very highly predictive ofwhether the user will associate the tag “skiing” with the conversation.Thus, two or more criteria may be used to select the most predictiveterms, a first criteria (based on a first heuristic value), whichevaluates the overall predictiveness of a particular term and a secondcriteria (based on a second heuristic value), which evaluates thepredictiveness of the term for entities of the N most popular entities(e.g., the top 50, or the top 20% entities) in the user's conversations.

After selecting the most predictive terms, the conversation server 700determines (2168) term weights for each of the selected predictiveterms. In some embodiments, the term weights are determined based on anon-contextual criteria such as the frequency with which the term isassociated with conversations in which the user is a participant. Insome embodiments, each term has a default term weight (e.g., 1), whichis adjusted by the conversation server 700. In some embodiments a termwhich does not have a weight is presumed to have a weight of 1.

In some embodiments, as discussed in greater detail above with referenceto FIG. 17A, the conversation server 700 accesses a conversation inwhich a user is a participant, obtaining a conversation profile for theconversation, where the conversation profile is based on informationincluding content of the conversation. The conversation server 700 alsoaccesses a plurality of entity profiles corresponding to the user;compares at least a subset of the entity profiles to the conversationprofile to identify a set of entities having entity profiles that bestmatch the conversation profile; generates a suggestion including asuggested entity from the identified set of entities; and sends thesuggestion to the client system for display. In some embodiments, eachentity profile corresponds to a respective entity in other conversationsin which the user is a participant and is based on an internal structureof content in those other conversations. Stated another way, in someembodiments the entity profile is based on metrics of the user'sinteraction with respective portions of the content in respectiveconversations that include the entity and in which the user is aparticipant.

Attention is now directed towards FIG. 17F, which illustrates a methodfor adjusting the weight of content in a respective conversation basedon an internal structure of content in the respective conversation. Itshould be understood that, in some embodiments the weight of content ina plurality of respective conversations is adjusted (e.g., whengenerating an entity profile, as described above in greater detail withreference to FIG. 17B), while in other embodiments the weight of contentin a single respective conversation is adjusted (e.g., when generating aconversation profile for a single conversation, as described above ingreater detail with reference to FIG. 17C). It should also be understoodthat, in some embodiments the weight of content is used to adjust termcounts, as illustrated in FIGS. 17B and 17C. However, in otherembodiments, the weight of content is used to generate entity profilesand conversation profiles in other ways (e.g., by generating theentity/conversation profiles using only content that has a weight abovea predefined threshold).

In some embodiments, the conversation server 700 identifies (2170) asubset of the conversation. For example, the subset can be a contentcontribution (2172). A content contribution can be a content unit (e.g.,a segment of text entered by a user such as an email or an instantmessage), or a report, meeting agenda, pictures, presentations, audiofiles, video files, or virtually any other type of electronic document,as described in greater detail above. In another example, the identifiedsubset of the content is (2174) a term (e.g., a single word or group ofcharacters without any intervening white space characters such as spacesor periods).

In some embodiments, after identifying the subset, the conversationserver 700 identifies (2176) features that indicate a strong connectionbetween the user and the subset. In some embodiments, the respectiveentity represents (2178) a contact of the user; and the internalstructure of the respective other conversation indicates (2180) thestrong connection (e.g., a strong connection between the user and thesubset of content) when the subset of the respective other conversationincludes one or more of: a contribution (2182) by the contact to contentthat was created by the user, a contribution (2184) by the user tocontent that was created by the contact, and content that wasconcurrently edited (2186) by the user and the contact.

In other words, in some embodiments, an occurrence of a term in a subsetof the conversation (e.g., a blip or content unit of the conversation)that was written in direct response to a subset of the conversation thatwas contributed by the user is more likely to be relevant and thus isweighted more heavily than the same term in a part of the conversationwhere the user is only a passive participant. Similarly, in someembodiments the number of conversation contributions positioned betweenthe term and the last conversation contribution by the user is used as ametric to weight the occurrences of a term when counting the occurrencesof that term. For example if Anne adds a conversation contribution to aconversation and Bob responds to Anne's conversation contribution, theterms in Bob's conversation contribution will be given greater weightthan a subset of the conversation that is remote from the subset thatincludes Anne and Bob's respective contributions.

It should be understood, that in some embodiments, the internalstructure of a conversation also indicates a strong connection betweenthe user and the subset of the conversation that is entity-specific. Asone example, take a conversation that includes three participants, Anne,Bob and Carol, and includes a respective subset that was concurrentlyedited by Anne and Bob, but which Carol has not edited. When theconversation server 700 generates an entity profile for the entity“Anne” in a user-account for Bob, the respective subset that wasconcurrently edited by Anne and Bob is strongly connected with both Boband Anne, and therefore is weighted very heavily in generating an entityprofile for the entity “Anne.” In other words, this concurrently editedrespective subset is likely to contain terms that Anne and Bob use whentalking to each other, and thus is likely to be predictive of when theentity “Anne” should be associated with one of Bob's conversations. Incontrast, when generating an entity profile for the entity “Carol” inthe user-account for Bob, the respective subset that was concurrentlyedited by Anne and Bob is only strongly associated with Bob, and thus isnot weighted as heavily in generating an entity profile for the entity“Carol” as it would have been in generating an entity profile for theentity “Anne.” In other words, this concurrently edited respectivesubset is less likely to be predictive of when the entity “Carol” shouldbe associated with one of Bob's conversations, because Carol did notparticipate in the respective subset. However, it should be understood,that even though the respective subset that was concurrently edited byBob and Anne is not strongly related to “Carol,” the content of thisrespective subset may still have a greater weight than a predefinednormal weight because Bob has contributed to this respective subset andtherefore it is likely relevant to Bob. In other words, even thoughCarol did not participate in creating the respective subset, therespective subset still contains terms that are important to Bob in aconversation in which Carol is a participant and therefore may bepredictive of when the entity “Carol” should be associated with aconversation.

In some embodiments, when the entity is a categorization entity (e.g.,metadata such as a tag, a label or an assigned folder), the internalstructure of the conversation indicates a strong connection between theuser and the metadata (e.g., a tag) when the tag or other metadata isapplied to a “private” sub-conversation (see discussion above concerningFIG. 3A) in which the user is a participant; when the tag or othermetadata is applied to text in the conversation contributed by the user;and when the tag or other metadata is added to the conversation by theuser.

In some embodiments, the internal structure of the respective otherconversation indicates (2192) a strong connection to the user when thesubset of the respective other conversation includes one or more ofcontent added (2194) by the user; content edited (2196) by the user; aresponse (2198) from another participant to content added by the user;and recently added (2200) content. For example, in some embodiments aconversation is generated by adding and editing subunits over anextended period of time (e.g., a period of days, weeks or months). Insuch embodiments, a subunit that was added or edited in the last day hasgreater weight than a subunit that was added or edited more than threeweeks ago. It should be understood that these metrics of internalstructure of the conversation may be used separately or in combination.

In some embodiments, when the internal structure of content of one ofthe respective other conversations indicates (2202) a strongerconnection between the user and a subset of the respective conversationthan for other subsets of the respective conversation (e.g., asdescribed in greater detail above), the conversation server 700 gives(2204) greater weight than a predefined normal weight to content in thesubset of the conversation. In some embodiments, when the conversationserver 700 is generating an entity profile, as described in greaterdetail above with reference to FIG. 17B, the conversation server 700generates an entity profile for the respective entity by giving greaterweight than a predefined normal weight to content in the subset of therespective other conversation having the stronger connection to the userthan content in subsets of one or more other conversations that are alsoassociated with the entity. In some embodiments, when the conversationserver 700 is generating a conversation profile, as described in greaterdetail above with reference to FIG. 17C, the conversation server 700generates a conversation profile for the respective conversation bygiving greater weight than a predefined normal weight to content in thesubset of the respective conversation having a strong connection to theuser than to content in other subsets of the same conversation. In otherwords, in embodiments where entity/conversation profiles are generatedbased on a term count, when the internal structure of the respectiveconversation indicates a strong connection between the user and a subsetof the conversation, the counted occurrences of terms in the subset ofthe conversation are given greater weight than a predefined normalweight.

In some embodiments, when the internal structure of content of one ofthe respective other conversations does not indicate (2206) a strongerconnection between the user and a subset of the respective otherconversation than for other subsets of the other conversation, theconversation server 700 maintains the predefined normal weight ofcontent in the subset of the respective conversation.

It should be understood that in some embodiments the entity/conversationprofile is normalized, so that there is no difference between increasingthe weights of some terms and, alternatively, increasing the weights ofsome terms while decreasing the weights of other terms. However, in someembodiments, when the internal structure of the respective conversationindicates a weak connection between the user and a subset of theconversation, the counted occurrences of terms in the subset of theconversation are given less weight than the predefined normal weight.For example, terms in conversation contribution unrelated to the entityare given a half count, while terms in conversation contributionssomewhat related to the entity are given a single count and terms inconversation contributions highly related to the entity are given adouble count.

In some embodiments, the conversation server 700 repeats the process fora plurality of subsets of the respective conversation. In other words,when the conversation server 700 determines that there are (2208) moresubsets of the respective conversation to examine, the conversationserver 700 selects a new subset from the same conversation and repeatsthe process described above. In contrast, when the conversation server700 determines that there are (2210) not any more subsets to examine,the subset weighting process ends (2212) for the respectiveconversation. It should be understood that other processes could also beperformed to adjust the entity/conversation profile, as described ingreater detail above with reference to FIGS. 5B-5C. Additionally, itshould be understood that the process could be repeated for one or moreadditional respective conversations, as described in greater detailabove with reference to FIG. 5B.

It should be understood that one of the advantages of conversations asdisclosed herein is that the internal structure of the conversations isdirectly observable by each participant and thus no historicalinformation is required. Instead, the conversations themselves alreadyinclude metadata indicative of editing information and responseinformation which is available to each participant in the conversation.Thus, there is no need to look at logs or other historical/archiveddata, because the metadata of the conversation can be directly examinedto determine if two users were collaboratively editing the conversationor if one subset of the conversation (e.g., conversation contribution)was added in response to another subset of the conversation (e.g.,conversation contribution). In other words, due to the structure of theconversation, responses to a portion of the content are directlyobservable, because conversations include a nested reply structure.Moreover, information that indicates even closer coupling of theresponses of participants is available in the form of metadataidentifying one or more collaboratively edited subsets of theconversation. For example, metadata identifying a subset of theconversation that was collaboratively edited by a group of two or moreparticipants at approximately the same time indicates, for a respectiveparticipant of the group, a connection between the content of the subsetand the other participants in the group that is stronger than aconnection between the content of the subset and participants in theconversation that are not in the group (i.e., who did notcollaboratively edit the subset of the conversation with the respectiveparticipant).

Attention is now directed towards FIG. 18A, which is a block diagramillustrating an exemplary user profile database 768 in accordance withsome embodiments. The user profile database 768 includes profiles 2230for a plurality of distinct users. Each user profile includes one ormore entity Ms 2232, and a plurality of additional terms 2238. Eachentity ID 2232 is associated with an affinity score 2234 and an entityprofile 2236. Each additional term 2238 is associated with a term weight2240. Affinity scores 2234 are determined on a per-user basis andindicate the non-contextual importance of the entity to the user. Forexample if a user has a tag that appears on 50% of his conversations,then that entity will have a high affinity score, while a contact thathas been a participant in 5% of the user's conversations will have arelatively low affinity score. Terms 2238 are selected on a per-userbasis, as described in greater detail above with reference to FIG. 17E,and term weights 2240 are determined on a per-user basis and indicatethe non-contextual importance of the term to the user. For example, aterm that appears in more conversations in which the user is aparticipant will have a higher term weight.

In some embodiments an entity profile 2236 includes a vector in termspace, where a context weight is computed for each of the terms in theuser's profile. For example, the profile 2230-2 of user 2 includes terms1-term X and therefore, the entity vector 2239 for entity 2 includescontext weights for each of term 1-term X. In some embodiments, thevector is a sparse entity vector 2241, and thus includes only terms forwhich the context weights are nonzero. A context weight for a term in anentity vector associated with an entity are calculated based on thenumber of occurrences of the respective term in conversations with whichthe entity is associated, as described in greater detail above withreference to FIG. 17B. An exemplary formula for calculating contextweights is described in greater detail below with reference to FIG. 18B.FIG. 18A shows highly simplified context weights for purposes ofillustration; these context weights do not take into account theadjustments identified in FIG. 18B.

Attention is now directed towards FIG. 18B, which includes an exemplaryformula for calculating context weights for an entity profile inaccordance with some embodiments. The context weight for a term (e.g.,“Context weight (term 2)”) is equal to the sum for conversation1-conversation z of a value calculated for each conversation. For arespective conversation (“conversation i”) in the conversation, thenumber of occurrences of the term (e.g., term 2) is counted (e.g., “term2 count”). If the count is zero, then the context weight is set to zero.If the count is greater than or equal to 1, and the count islogarithmically discounted (e.g., “1+log₂ (term 2 count)). (It should beunderstood that other methods for discounting subsequent occurrences ofa term beyond the first could be used; the log base 2 discounting ismerely exemplary; logarithms other than base 2 and other discountingfunctions could also be used). The discounted term count is combinedwith a term weight (e.g., “term 2 weight”) for the term, and thennormalized (e.g., “Norm( )”) with the rest of the conversation vector,as described previously with reference to FIG. 17B. The normalized,weighted, logarithmically adjusted term count is then adjusted by theage of the conversation (e.g., “age adjustment for conversation i”), asdescribed previously with reference to FIG. 17B. The sum of these valuesover all of the conversations is equal to the context weight for theterm in the entity vector.

It should be understood that the process of determining context weightsfor the terms in a set of entity vectors is completed on a per-userbasis. Additionally, in some embodiments, the context weights for theterms in all of the entity profiles for all of the entities in the userprofile are generated in a single operation (i.e., the user's entireprofile is rebuilt at once, and is not incrementally updated). In someembodiments this set of entity profiles 2236 and affinity scores 2234 iscalled a model for the user. It should be understood that in accordancewith some embodiments, there are no global evaluations of terms, ratherterms are evaluated on a per-user basis. Thus, in these embodiments, theuser profile of each user is completely self-contained and is notinfluenced by conversations in which the user is not a participant.

Attention is now directed towards FIG. 18C, which illustrates aconversation profile database 770 in accordance with some embodiments.The conversation profiles are generated on a per-user basis. In someembodiments a conversation profile 2236, for use by the conversationserver 700 to compare with the entity profiles for a user, includes avector in term space, where a context weight is computed for each of theterms (e.g., term 1-term X 2238) in the user's profile. In someembodiments, each conversation profile 2242 includes a conversationvector 2244 or a sparse conversation vector 2246. For example,conversation profile 2 is generated by the conversation server tocompare with the entity profiles for user 2 (2230-2 in FIG. 18A), whereuser 2 has a profile that includes a set of terms, term 1-term X, andtherefore the conversation vector 2244 for a conversation being editedby the user (e.g., for conversation profile 2) includes context weightsfor each of term 1-term X. In some embodiments, the vector is a sparsecontext vector 2246, and thus includes only terms for which the contextweights are nonzero. A context weight for a term in a conversationvector 2244 associated with a conversation in which the user is aparticipant is calculated based on the number of occurrences of therespective term in conversation, as described in greater detail abovewith reference to FIG. 17C. An exemplary formula for calculating contextweights for a conversation is described in greater detail below withreference to FIG. 18D.

In some embodiments the conversation profile database 770 is a cache,and conversation profiles 2242 are only temporarily stored in the cachebefore being updated or purged from the cache.

Attention is now directed towards FIG. 18D, which includes an exemplaryformula for calculating context weights for a conversation profile inaccordance with some embodiments. In some embodiments, the contextweight for a term in a conversation (e.g., “Context weight (term 1)”) isbased on a logarithmically discounted count of the occurrences of a termin the conversation. The number of occurrences of the term (e.g.,term 1) is counted (e.g., “term 1 count”). If the count is zero, thenthe context weight is set to zero. If the count is greater than or equalto 1, and the count is logarithmically discounted (e.g., “1+log₂ (term 1count)). It should be understood that other methods for discountingsubsequent occurrences of a term beyond the first could be used. The logbase 2 discounting is merely exemplary, and thus logarithms other thanbase 2 and other discounting functions could also be used. Thediscounted term count is combined with a term weight (e.g., “term 1weight”) for the term from the user profile of the user who isparticipating in the conversation (e.g., 2240-1 in FIG. 18A) to producethe context weight for the term.

It should be understood that this process of generating a conversationprofile is completed on a per-user basis. In other words, for aconversation with a plurality of participants, a conversation profilegenerated with respect to a first participant would be different than aconversation profile generated with respect to a second participant,because the set of terms (e.g., term 1-term X 2238 in FIG. 18C) that areused to generate the conversation profile and the set of term weights(e.g., 2240 in FIG. 18A) are specific to each user. In some embodiments,one or more of the conversations include private content units (e.g.,private blips or private replies), and thus the specificity is due atleast in part to the fact that different users have different views ofthe conversation. For example if user A, user B and user C are allparticipants in a conversation, and user A and user B are participantsin a private content unit (e.g., a “private reply”) within theconversation that does not include user C as a participant, then theterms in the private content unit are used to generate entity profilesand the conversation profile for the conversation for user A and user B,while the terms in the private content unit are not used to generateentity profiles and the conversation profile for user C (e.g., becauseuser C cannot “see” the private content unit). The conversation profileis compared with entity profiles as described in greater detail abovewith reference to FIGS. 17A and 17D.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

1-20. (canceled) 21: A method comprising: maintaining a plurality ofconversations that each has an identified set of participants, whereinthe plurality of conversations are instant messaging conversations; foreach respective participant in each of the plurality of conversations,maintaining a respective participant-specific index of terms associatedwith one or more of the plurality of conversations in which therespective participant is an identified participant; and responsive toreceiving a search request from a first participant in a firstconversation of the plurality of conversations: using the respectiveparticipant-specific index of terms corresponding to the firstparticipant to identify one or more search results, wherein the one ormore search results include one or more of (a) at least one conversationof the plurality of conversations that matches the search request, or(b) content included in the at least one conversation that matches thesearch request, wherein the first participant is a participant in the atleast one conversation; and providing a display of the one or moresearch results. 22: The method of claim 21, wherein the one or moresearch results includes the content included in the at least oneconversation that matches the search request, and wherein the contentincluded in the at least one conversation comprises one or moreattachments to the at least one conversation. 23: The method of claim22, wherein the one or more attachments comprise one or more of apicture, a video file, a document, an archive, an audio file, apresentation, an animation, or a link. 24: The method of claim 21,further comprising: for each respective participant in each of theplurality of conversations, updating the respective participant-specificindex of terms based on new content that is added to the one or more ofthe plurality of conversations in which the respective participant is anidentified participant. 25: The method of claim 21, wherein the at leastone conversation includes the first conversation. 26: The method ofclaim 21, wherein the at least one conversation includes a secondconversation different from the first conversation. 27: The method ofclaim 26, wherein providing the display of the one or more searchresults comprises formatting all or a portion of the second conversationfor display to the first participant. 28: The method of claim 26,wherein providing the display of the one or more search resultscomprises providing a display of content included in the secondconversation that matches the search request. 29: The method of claim26, further comprising: prior to receiving the search request: receivinga message from a second participant of the second conversation; andupdating, based on the message, respective participant-specific indexesfor each identified participant of the second conversation, includingthe participant-specific index of terms for the first participant. 30:The method of claim 21, further comprising: maintaining, for the firstparticipant, a list of the plurality of conversations in which the firstparticipant is an identified participant; updating a status of eachconversation in the list when a state of the respective conversationchanges; and providing a display of the respective updated status ofeach conversation in the list when the state of the respectiveconversation changes. 31: The method of claim 21, wherein the respectiveidentified set of participants of the first conversation include one ormore subscriber participants and one or more non-subscriberparticipants. 32: The method of claim 31, wherein the one or morenon-subscriber participants include one or more of an email client or aweb log client. 33: A computer system, comprising: one or moreprocessors; a memory configured to store instructions that areexecutable by the one or more processors to: maintain a plurality ofconversations that each has an identified set of participants, whereinthe plurality of conversations are instant messaging conversations; foreach respective participant in each of the plurality of conversations,maintain a respective participant-specific index of terms associatedwith one or more of the plurality of conversations in which therespective participant is an identified participant; and responsive toreceiving a search request from a first participant in a firstconversation of the plurality of conversations: use the respectiveparticipant-specific index of terms corresponding to the firstparticipant to identify one or more search results, wherein the one ormore search results include one or more of (a) at least one conversationof the plurality of conversations that matches the search request, or(b) content included in the at least one conversation that matches thesearch request, wherein the first participant is a participant in the atleast one conversation; and provide a display of the one or more searchresults. 34: The computer system of claim 33, wherein the one or moresearch results includes the content included in the at least oneconversation that matches the search request, and wherein the contentincluded in the at least one conversation comprises one or moreattachments to the at least one conversation. 35: The computer system ofclaim 34, wherein the one or more attachments comprise one or more of apicture, a video file, a document, an archive, an audio file, apresentation, an animation, or a link. 36: The computer system of claim33, wherein the instructions are further executable by the one or moreprocessors to: for each respective participant in each of the pluralityof conversations, update the respective participant-specific index ofterms based on new content that is added to the one or more of theplurality of conversations in which the respective participant is anidentified participant. 37: The computer system of claim 33, wherein therespective identified set of participants of the first conversationinclude one or more subscriber participants and one or morenon-subscriber participants. 38: The computer system of claim 37,wherein the one or more non-subscriber participants include one or moreof an email client or a web log client. 39: A non-transitorycomputer-readable storage medium storing instructions that, whenexecuted, cause one or more processors of a computer system to: maintaina plurality of conversations that each has an identified set ofparticipants, wherein the plurality of conversations are instantmessaging conversations; for each respective participant in each of theplurality of conversations, maintain a respective participant-specificindex of terms associated with one or more of the plurality ofconversations in which the respective participant is an identifiedparticipant; and responsive to receiving a search request from a firstparticipant in a first conversation of the plurality of conversations:use the respective participant-specific index of terms corresponding tothe first participant to identify one or more search results, whereinthe one or more search results include one or more of (a) at least oneconversation of the plurality of conversations that matches the searchrequest, or (b) content included in the at least one conversation thatmatches the search request, wherein the first participant is aparticipant in the at least one conversation; and provide a display ofthe one or more search results.